[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <534f113b-546b-4795-83a1-b87b67727302@t-8ch.de>
Date: Fri, 30 Jun 2023 21:55:47 +0200
From: Thomas Weißschuh <thomas@...ch.de>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Willy Tarreau <w@....eu>,
Zhangjin Wu <falcon@...ylab.org>
Subject: Re: [PATCH] mm: make MEMFD_CREATE into a selectable config option
On 2023-06-30 08:32:36-0700, Darrick J. Wong wrote:
> On Fri, Jun 30, 2023 at 11:08:53AM +0200, Thomas Weißschuh wrote:
> > The memfd_create() syscall, enabled by CONFIG_MEMFD_CREATE, is useful on
> > its own even when not required by CONFIG_TMPFS or CONFIG_HUGETLBFS.
>
> If you don't have tmpfs or hugetlbfs enabled, then what fs ends up
> backing the file returned by memfd_create()? ramfs?
ramfs, correct.
It goes via mm/memfd.c -> mm/shmem.c -> fs/ramfs/ .
Thomas
> (Not an objection, I'm just curious...)
>
> --D
>
> > Split it into its own proper bool option that can be enabled by users.
> >
> > Move that option into mm/ where the code itself also lies.
> > Also add "select" statements to CONFIG_TMPFS and CONFIG_HUGETLBFS so
> > they automatically enable CONFIG_MEMFD_CREATE as before.
> >
> > Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
> > ---
> > fs/Kconfig | 5 ++---
> > mm/Kconfig | 3 +++
> > 2 files changed, 5 insertions(+), 3 deletions(-)
> [..]
Powered by blists - more mailing lists