From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD8B8C54798 for ; Wed, 28 Feb 2024 01:31:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 46ABA80017; Tue, 27 Feb 2024 20:31:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F40380015; Tue, 27 Feb 2024 20:31:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 293A580017; Tue, 27 Feb 2024 20:31:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 173AA80015 for ; Tue, 27 Feb 2024 20:31:44 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B6BF81403A5 for ; Wed, 28 Feb 2024 01:31:43 +0000 (UTC) X-FDA: 81839485686.20.30CE042 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by imf30.hostedemail.com (Postfix) with ESMTP id 1AABD80012 for ; Wed, 28 Feb 2024 01:31:40 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UuZfnZgc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf30.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709083901; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tQB+JZ1G68ICyO1N3p0oqOVpl3RnCmkeQUi97bJMYlw=; b=FmtSJzll6h+hqy0PkdOmyAibu4v9TWFuZehk9iyzqQF40dtin+MYo/YCe6vYgcM2pD/sdO OZ+Xer80EyYnZfoKSD8a+mIdcqg7TH58efZ+/TVM6lL+jNFng7+Wtt1k0VN0+H7qvIADtf qTAFpgFxeYrjjg/s0SZNGT67jTNUdqo= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UuZfnZgc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf30.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709083901; a=rsa-sha256; cv=none; b=0Zl4Ma2CxbKM67BMHzKRJDzpcnaUAPOgM9DX/e5FRchEQ/R5bfwTCjfYwkRrm7py1ucmGV LkA4I08YPFB75vHhoOhEg2mkDVWSJvCFXMZg2BJx2NJe4A9A9kNSjPkk5+70yKOW1RPByp oeHlFU90Kn4KOO0GbJPiH/l6cz0hvf0= Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-33d28468666so4259818f8f.0 for ; Tue, 27 Feb 2024 17:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709083900; x=1709688700; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tQB+JZ1G68ICyO1N3p0oqOVpl3RnCmkeQUi97bJMYlw=; b=UuZfnZgcewOWj4LgqOLCa7H6AGKYDYfNRxWoQo1TkMFN21dG4NTIcm1gBDaNDXJ6TS L9uw6nhaM5qICwzNXbKN4wIwEBgGuKK98C4utq4164CU4nehj9BY2KOef/F0hAM8rulu DYNK2EgxAApsWHsUCAKRnMojvSIYwo2h3sj0u8R4+9hxk7+SN6kDhe4ObeNvCQJaMuf+ 80CXhvF1tLnn+PLeOA2+6B+dF7+G1VK4WO5TMOxgyOZbxlJsIOfwR+2gqx/EbaPTMI8n pN6pjXaUUM0LD9Jy3rjL7ElXNI3LgQ/IsGI6EFQPLn/734zCA9YzSdeg5KHuGpON/xJV 7i2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709083900; x=1709688700; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tQB+JZ1G68ICyO1N3p0oqOVpl3RnCmkeQUi97bJMYlw=; b=qNtHxTPXptyoSDxyZseFneB2y2AUqWYiiVS0/yzUiTjRvy75OTbU97OGIdsCJHOfZf sLf2q6lEeHPt/ZTy3k7cnfLyPARA5EmndVxWA4tcDSTFs3AagD6uH1gsZzMrFVaU/JXR lNwvdJ8S1aF3lDhsRtRsIwgQJSPdmRHRJkKXjP9+QyEJykvpvb3dAc+lr5QEvJtItFw2 ZH1Ofnu8JXmmpFXXNSWandWxb+PwMSmhq73TPChvjhMxc3ZcRCLUV7GXOOUik6K5PGq3 5CLhpvWmpTApwqoY28rTWKxzx6wGPHiAg9a2akW8j6NhMOqE5pzRasw3AW7xfhDQ85PR PSxg== X-Forwarded-Encrypted: i=1; AJvYcCWudoLFue0ms19mM0aU3gd09Awt53XiyVDGSaz8VZAjZyNuCKyRKWZGtymIbdHIwoUL//pQhN/D0uLBX41PdsMEF0w= X-Gm-Message-State: AOJu0YxcWHbwqaPMep9TYytMADkraDmBOA/zgT+PjPjiNEBQzawlyiBG EXo7KicILzLw9lcT5iJUo/vhCacrVonUt38q7LTk5S4BOy2JhzO4s9qmJ5FAWp63dh9gO6mz52S HNkjhJfbvheeyjZL+jiJrCXYBFs4= X-Google-Smtp-Source: AGHT+IHW0RvW1Yw8eRC97o+L4oxzxSjZSar1xugDudti2CXKZy7764qOr6NgwPLSJiP97CBaYnawADxltOlqy8AvltM= X-Received: by 2002:adf:db07:0:b0:33d:82ae:67f8 with SMTP id s7-20020adfdb07000000b0033d82ae67f8mr8131519wri.50.1709083899508; Tue, 27 Feb 2024 17:31:39 -0800 (PST) MIME-Version: 1.0 References: <20240223235728.13981-1-alexei.starovoitov@gmail.com> <20240223235728.13981-4-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Tue, 27 Feb 2024 17:31:28 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 3/3] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). To: Christoph Hellwig Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Linus Torvalds , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Boris Ostrovsky , sstabellini@kernel.org, Juergen Gross , linux-mm , xen-devel@lists.xenproject.org, Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 1AABD80012 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: opati84qt8wc75zxubukuondehjkk1nr X-HE-Tag: 1709083900-425180 X-HE-Meta: U2FsdGVkX1+KYTeQS59s95zLDr8p4YtHCjtLb9ca4OT8PGkpRmvA3UZY6JXLpAQrgcDrxRQCH+P0HuKe/pUmkjp3DU93bpVlNWfNAzMFEppHOAW4E57vA8IjzrDCvLlHQDwnKFn06wl/jhR+/0jlQN+f2eETQMshbe0HzevpI4XW/NscEpeisuoS2Xq5yzehDFw0Q9R/8zL5Ljm7rA6t0ONPO6Pm9zqnbc8P640wKvR0LsZjgdwbSKG66QAejzttMC5UFgmFnLZykIy/+YI+brPR192OXH4LGoCk3FPed21dhOn76QEaGJhk3IYJFj4Ci9w2kxJgH6bpX6I3NMUcap7Jc+P4IPa4YXUdauJx1MsxrKWI/wmTTwPhLf1ylVXrmwZBeaoYNyA+66PEpZRYyy+AiouovKP9CXnS9yaq7flIKHx3+xIo+fjMI2JTb7VGzAxf01kp+tiqHg9HGVcK8F8rsxLKNiJFxj/Ful0SB862h3IpoFweTgecu+78wQX+tPAyO3IfBu0LUIC7KFsimuI4R0U4UhU7DSN5qYkgeMRr4u/8rxyfsizaTA7KpHcpgd50V6QP9lfm+g/cInAJuL8DzZaOnhjL2hnIsAz/0ZdSc22/frI8KOJlWQpiXt4Jb44Rvz3XBnxGtzdXDgTgFdP1oYsIiWEkg8xP+hHwZjcBgvJ8SP8M7LquJJo8wNMXejLmqm75E/btTajLCN4N8orkIfyUzsaQFf8uHgUXXKNKzn2nYBOeBfuhuwV/QVXz8thIyJNd0rCd4pspKvg+zCS9tBnOkBgFWQkhYrGXQVBzTwZNjz7OOhpuyXjQhjcNGl8ARFNDosRW6QvoQ667wy/3Nz3Qilwt/H3x6BvWO3STjk/C3EJcph/6lDXFR2bfadsj5xDh6YuBdYtIVA3abedz+YIM3q1SFN5Wc9dmzjDxBpVxx9uvSBvqm/Z0PGLJDa5kbe24KVfkRA3Zsgu C813ANja sRGzWKtVxPCFPUaKG6buNzvA/rcWc1JtgLbK/laCl0L5Incwc3gY90XWJYvf+e3ZFe5MHoevLfn52ZRKIhkSLzl1H9tSgvs4APhtNku0z2kSpaSl44YOrQ2lFsw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Feb 27, 2024 at 9:59=E2=80=AFAM Christoph Hellwig wrote: > > > privately-managed pages into a sparse vm area with the following steps: > > > > area =3D get_vm_area(area_size, VM_SPARSE); // at bpf prog verificat= ion time > > vm_area_map_pages(area, kaddr, 1, page); // on demand > > // it will return an error if kaddr is out of range > > vm_area_unmap_pages(area, kaddr, 1); > > free_vm_area(area); // after bpf prog is unloa= ded > > I'm still wondering if this should just use an opaque cookie instead > of exposing the vm_area. But otherwise this mostly looks fine to me. What would it look like with a cookie? A static inline wrapper around get_vm_area() that returns area->addr ? And the start address of vmap range will be such a cookie? Then vm_area_map_pages() will be doing find_vm_area() for kaddr to check that vm_area->flag & VM_SPARSE ? That's fine, but what would be an equivalent of void free_vm_area(struct vm_struct *area= ) ? Another static inline wrapper similar to remove_vm_area() that also does kfree(area); ? Fine by me, but api isn't user friendly with such obfuscation. I guess I don't understand the motivation to hide 'struct vm_struct *'. > > + if (addr < (unsigned long)area->addr || (void *)end > area->addr = + area->size) > > + return -ERANGE; > > This check is duplicated so many times that it really begs for a helper. ok. will do. > > +int vm_area_unmap_pages(struct vm_struct *area, unsigned long addr, un= signed int count) > > +{ > > + unsigned long size =3D ((unsigned long)count) * PAGE_SIZE; > > + unsigned long end =3D addr + size; > > + > > + if (WARN_ON_ONCE(!(area->flags & VM_SPARSE))) > > + return -EINVAL; > > + if (addr < (unsigned long)area->addr || (void *)end > area->addr = + area->size) > > + return -ERANGE; > > + > > + vunmap_range(addr, end); > > + return 0; > > Does it make much sense to have an error return here vs just debug > checks? It's not like the caller can do much if it violates these > basic invariants. Ok. Will switch to void return. Will reduce commit line logs to 75 chars in all patches as suggested. re: VM_GRANT_TABLE or VM_XEN_GRANT_TABLE suggestion for patch 2. I'm not sure it fits, since only one of get_vm_area() in xen code is a grant table related. The other one is for xenbus that creates a shared memory ring between domains. So I'm planning to keep it as VM_XEN in the next revision unless folks come up with a better name. Thanks for the reviews.