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@google.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
diff --git a/include/uapi/linux/restrictedmem.h b/include/uapi/linux/restrictedmem.h
new file mode 100644
index 000000000000..9f108dd1ac4c
--- /dev/null
+++ b/include/uapi/linux/restrictedmem.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_RESTRICTEDMEM_H
+#define _UAPI_LINUX_RESTRICTEDMEM_H
+
+/* flags for memfd_restricted */
+#define RMFD_TMPFILE 0x0001U
+
+#endif /* _UAPI_LINUX_RESTRICTEDMEM_H */
diff --git a/mm/restrictedmem.c b/mm/restrictedmem.c
index c5d869d8c2d8..97f3e2159e8b 100644
--- a/mm/restrictedmem.c
+++ b/mm/restrictedmem.c
@@ -1,11 +1,12 @@
// SPDX-License-Identifier: GPL-2.0
-#include "linux/sbitmap.h"
+#include <linux/namei.h>
#include <linux/pagemap.h>
#include <linux/pseudo_fs.h>
#include <linux/shmem_fs.h>
#include <linux/syscalls.h>
#include <uapi/linux/falloc.h>
#include <uapi/linux/magic.h>
+#include <uapi/linux/restrictedmem.h>
#include <linux/restrictedmem.h>
struct restrictedmem {
@@ -189,19 +190,20 @@ static struct file *restrictedmem_file_create(struct file *memfd)
return file;
}
-SYSCALL_DEFINE1(memfd_restricted, unsigned int, flags)
+static int restrictedmem_create(struct vfsmount *mount)
{
struct file *file, *restricted_file;
int fd, err;
- if (flags)
- return -EINVAL;
-
fd = get_unused_fd_flags(0);
if (fd < 0)
return fd;
- file = shmem_file_setup("memfd:restrictedmem", 0, VM_NORESERVE);
+ if (mount)
+ file = shmem_file_setup_with_mnt(mount, "memfd:restrictedmem", 0, VM_NORESERVE);
+ else
+ file = shmem_file_setup("memfd:restrictedmem", 0, VM_NORESERVE);
+
if (IS_ERR(file)) {
err = PTR_ERR(file);
goto err_fd;
@@ -223,6 +225,55 @@ SYSCALL_DEFINE1(memfd_restricted, unsigned int, flags)
return err;
}
+static bool is_shmem_mount(struct vfsmount *mnt)
+{
+ return mnt->mnt_sb->s_magic == TMPFS_MAGIC;
+}
+
+static int restrictedmem_create_from_path(const char __user *mount_path)
+{
+ int ret;
+ struct path path;
+
+ ret = user_path_at(AT_FDCWD, mount_path,
+ LOOKUP_FOLLOW | LOOKUP_MOUNTPOINT,
+ &path);
+ if (ret)
+ return ret;
+
+ if (!is_shmem_mount(path.mnt)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ ret = mnt_want_write(path.mnt);
+ if (unlikely(ret))
+ goto out;
+
+ ret = restrictedmem_create(path.mnt);
+
+ mnt_drop_write(path.mnt);
+out:
+ path_put(&path);
+
+ return ret;
+}
+
+SYSCALL_DEFINE2(memfd_restricted, unsigned int, flags, const char __user *, mount_path)
+{
+ if (flags & ~RMFD_TMPFILE)
+ return -EINVAL;
+
+ if (flags == RMFD_TMPFILE) {
+ if (!mount_path)
+ return -EINVAL;
+
+ return restrictedmem_create_from_path(mount_path);
+ } else {
+ return restrictedmem_create(NULL);
+ }
+}
+
int restrictedmem_bind(struct file *file, pgoff_t start, pgoff_t end,
struct restrictedmem_notifier *notifier, bool exclusive)
{
--
2.39.1.637.g21b0678d19-googOn 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@google.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
"Kirill A. Shutemov" <kirill@shutemov.name> writes: > 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@google.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. I tried out the suggestion of passing fds to memfd_restricted() instead of strings. One benefit I see of using fds is interface uniformity: it feels more aligned with other syscalls like fsopen(), fsconfig(), and fsmount() in terms of using and passing around fds. Other than being able to use a mount without a path attached to the mount, are there any other benefits of using fds over using the path string? Should I post the patches that allows specifying a mount using fds? Should I post them as a separate RFC, or as a new revision to this RFC?
On Thu, Feb 23, 2023 at 12:55:16AM +0000, Ackerley Tng wrote: > > "Kirill A. Shutemov" <kirill@shutemov.name> writes: > > > 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@google.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. > > I tried out the suggestion of passing fds to memfd_restricted() instead > of strings. > > One benefit I see of using fds is interface uniformity: it feels more > aligned with other syscalls like fsopen(), fsconfig(), and fsmount() in > terms of using and passing around fds. > > Other than being able to use a mount without a path attached to the > mount, are there any other benefits of using fds over using the path string? It would be nice if anyone from fs folks comment on this. > Should I post the patches that allows specifying a mount using fds? > Should I post them as a separate RFC, or as a new revision to this RFC? Let's first decide what the right direction is. -- Kiryl Shutsemau / Kirill A. Shutemov
© 2016 - 2024 Red Hat, Inc.