[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230216100150.yv2ehwrdcfzbdhcq@box.shutemov.name>
Date: Thu, 16 Feb 2023 13:01:50 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Ackerley Tng <ackerleytng@...gle.com>
Cc: kvm@...r.kernel.org, linux-api@...r.kernel.org,
linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, qemu-devel@...gnu.org,
chao.p.peng@...ux.intel.com, aarcange@...hat.com,
ak@...ux.intel.com, akpm@...ux-foundation.org, arnd@...db.de,
bfields@...ldses.org, bp@...en8.de, corbet@....net,
dave.hansen@...el.com, david@...hat.com, ddutile@...hat.com,
dhildenb@...hat.com, hpa@...or.com, hughd@...gle.com,
jlayton@...nel.org, jmattson@...gle.com, joro@...tes.org,
jun.nakajima@...el.com, kirill.shutemov@...ux.intel.com,
linmiaohe@...wei.com, luto@...nel.org, mail@...iej.szmigiero.name,
mhocko@...e.com, michael.roth@....com, mingo@...hat.com,
naoya.horiguchi@....com, pbonzini@...hat.com, qperret@...gle.com,
rppt@...nel.org, seanjc@...gle.com, shuah@...nel.org,
steven.price@....com, tabba@...gle.com, tglx@...utronix.de,
vannapurve@...gle.com, vbabka@...e.cz, vkuznets@...hat.com,
wanpengli@...cent.com, wei.w.wang@...el.com, x86@...nel.org,
yu.c.zhang@...ux.intel.com
Subject: Re: [RFC PATCH 1/2] mm: restrictedmem: Allow userspace to specify
mount_path for memfd_restricted
On Thu, Feb 16, 2023 at 12:41:16AM +0000, Ackerley Tng wrote:
> By default, the backing shmem file for a restrictedmem fd is created
> on shmem's kernel space mount.
>
> With this patch, an optional tmpfs mount can be specified, which will
> be used as the mountpoint for backing the shmem file associated with a
> restrictedmem fd.
>
> This change is modeled after how sys_open() can create an unnamed
> temporary file in a given directory with O_TMPFILE.
>
> This will help restrictedmem fds inherit the properties of the
> provided tmpfs mounts, for example, hugepage allocation hints, NUMA
> binding hints, etc.
>
> Signed-off-by: Ackerley Tng <ackerleytng@...gle.com>
> ---
> include/linux/syscalls.h | 2 +-
> include/uapi/linux/restrictedmem.h | 8 ++++
> mm/restrictedmem.c | 63 +++++++++++++++++++++++++++---
> 3 files changed, 66 insertions(+), 7 deletions(-)
> create mode 100644 include/uapi/linux/restrictedmem.h
>
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index f9e9e0c820c5..4b8efe9a8680 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -1056,7 +1056,7 @@ asmlinkage long sys_memfd_secret(unsigned int flags);
> asmlinkage long sys_set_mempolicy_home_node(unsigned long start, unsigned long len,
> unsigned long home_node,
> unsigned long flags);
> -asmlinkage long sys_memfd_restricted(unsigned int flags);
> +asmlinkage long sys_memfd_restricted(unsigned int flags, const char __user *mount_path);
>
> /*
> * Architecture-specific system calls
I'm not sure what the right practice now: do we provide string that
contains mount path or fd that represents the filesystem (returned from
fsmount(2) or open_tree(2)).
fd seems more flexible: it allows to specify unbind mounts.
--
Kiryl Shutsemau / Kirill A. Shutemov
Powered by blists - more mailing lists