Message ID | 20230630-config-memfd-v1-1-9acc3ae38b5a@weissschuh.net |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp10229534vqr; Fri, 30 Jun 2023 02:46:11 -0700 (PDT) X-Google-Smtp-Source: APBJJlFsWVqmLwUM4yeC8mEc+PzlUAKE7H+wUa9OXvganBhBuoQuzLqmiSGzLGNLPFWHy+xcb1go X-Received: by 2002:a17:90a:e2c1:b0:263:25f9:65b2 with SMTP id fr1-20020a17090ae2c100b0026325f965b2mr2017858pjb.4.1688118371460; Fri, 30 Jun 2023 02:46:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688118371; cv=none; d=google.com; s=arc-20160816; b=wqfBRFe3o84HZUHf0S3NtSyOFZo8oX484g0ePN8ZIytzOFj5FBmk40L2qnOMWOL2Vl 004Qi3Xd2NBTIo9Uy6PDnMyW7FOdR4nIdmUdey+TKFm4nWdr0uUiSQ0O9IBgGTeNMOmm 5Hkzs2NJfyzbyHsA3qOa8XwBBvSh/vapWnO9TLL8Gu0v4Usyisw/H6m44jaRf15A8j2C 0wGiVXeBYRhMQCaIdZMqSXdb4TWHUxZ+3QWWHrAGH6ZmOEL+mCaZHxh0VP02ybW4X8t/ M2wo5CwEIfvPNq+dI7C2pxOJEplOC42/2/SVETCraEtMTAhCYCQ8/9LVZwtl/1klqRSm AySw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:dkim-signature:from; bh=vtT/XJToroaRvD1p4AP+5GbgoCpzejb0QSvFvOoAOaI=; fh=hY0bxp3JJMPlHoqRaRiK3nVRVGWXPYRBeHDK8rh713g=; b=VA34icHKGip3ycMwybHxyV+34AhPO3mq1sfe4EhOPsCwqiBBxqB/NGbpuZ+BOKMe2P 2cDxWsw2oNY6+xPn2wNJ7z06cIBmFv4aydNUBH2wMJi6mz3kF4xFiWxN1pOu8yCbNVCi xZA2ht0riD7Zjg57BQwpQBOi4HH3ks6hbN9GOQEmacopplz5tlnY54j7bBmU2JhD8vhf RgR0yC9t3HcoqzGLj7iEttWusfQbmR3Y10ms2PoGmwxIP0U0EMBplBHXSiLbRWuzaFEz R1zsJtO9MI0F9MxIRzxsm7OlulObRKzBW4moG+DwivkzOW2qUZY8Tu7vw5ukl/HM3IAW 4ODw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@weissschuh.net header.s=mail header.b=nAHp3GNW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 8-20020a17090a004800b0025baa49fa95si12114934pjb.1.2023.06.30.02.45.58; Fri, 30 Jun 2023 02:46:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@weissschuh.net header.s=mail header.b=nAHp3GNW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232460AbjF3JJI (ORCPT <rfc822;ivan.orlov0322@gmail.com> + 99 others); Fri, 30 Jun 2023 05:09:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231315AbjF3JJC (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 30 Jun 2023 05:09:02 -0400 Received: from todd.t-8ch.de (todd.t-8ch.de [159.69.126.157]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 02D9BE5E; Fri, 30 Jun 2023 02:09:01 -0700 (PDT) From: =?utf-8?q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=weissschuh.net; s=mail; t=1688116139; bh=OOAKwOFfZgl3msnuVjn16jsWxbjqhfuBBnZpLziJnjI=; h=From:Date:Subject:To:Cc:From; b=nAHp3GNWH3bIQbbJ7B2nTlLTXY9Xq9hWNzqd0TfTgHy3IlpLDeWD+dqQm7O/eXYKH 0K/WErRYqTmvh7xyi3fti32K8jO6hhbiSopGvMb1wcI5VLDlClgpI9DBF50J9KHfdA jEofzwLiPn0IJVU1BBMtLuj1xR1dkREs+FIaJFUk= Date: Fri, 30 Jun 2023 11:08:53 +0200 Subject: [PATCH] mm: make MEMFD_CREATE into a selectable config option MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <20230630-config-memfd-v1-1-9acc3ae38b5a@weissschuh.net> X-B4-Tracking: v=1; b=H4sIAKSbnmQC/6tWKk4tykwtVrJSqFYqSi3LLM7MzwNyDHUUlJIzE vPSU3UzU4B8JSMDI2MDMyNL3eT8vLTMdN3c1Ny0FN2kVLPENAPjJPOU5EQloJaCotS0zAqwcdG xtbUA9l1O0V4AAAA= To: Alexander Viro <viro@zeniv.linux.org.uk>, Christian Brauner <brauner@kernel.org>, Andrew Morton <akpm@linux-foundation.org> Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Willy Tarreau <w@lwt.eu>, Zhangjin Wu <falcon@tinylab.org>, =?utf-8?q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net> X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1688116137; l=2138; i=linux@weissschuh.net; s=20221212; h=from:subject:message-id; bh=OOAKwOFfZgl3msnuVjn16jsWxbjqhfuBBnZpLziJnjI=; b=kQBkkRFrqk5TKAAbU2s4iVjeJ2yAWu+HDlzAGyCqAqXUgKoaMED26dyk7Wz3UwkSiKAieqaCN wukedK6JuBXC9N+wJRWyCzBe5NaSB5lv8wz20O/k+hugFZlrp9EiaeA X-Developer-Key: i=linux@weissschuh.net; a=ed25519; pk=KcycQgFPX2wGR5azS7RhpBqedglOZVgRPfdFSPB1LNw= X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770120409693763913?= X-GMAIL-MSGID: =?utf-8?q?1770120409693763913?= |
Series |
mm: make MEMFD_CREATE into a selectable config option
|
|
Commit Message
Thomas Weißschuh
June 30, 2023, 9:08 a.m. UTC
The memfd_create() syscall, enabled by CONFIG_MEMFD_CREATE, is useful on
its own even when not required by CONFIG_TMPFS or CONFIG_HUGETLBFS.
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@weissschuh.net>
---
fs/Kconfig | 5 ++---
mm/Kconfig | 3 +++
2 files changed, 5 insertions(+), 3 deletions(-)
---
base-commit: e55e5df193d247a38a5e1ac65a5316a0adcc22fa
change-id: 20230629-config-memfd-be6af03b7dca
Best regards,
Comments
Hi, Thomas I have manually applied your patch on v6.4, enabled MEMFD_CREATE (and disabled TMPFS and HUGETLBFS) for 3 randomly selected virtual boards: - arm/vexpress-a9 - aarch64/virt - mipsel/malta For all of the above boards, the current vfprintf test (uses memfd_create) of tools/testing/selftests/nolibc/nolibc-test.c passes without any failure: Running test 'vfprintf' 0 emptymemfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL, pid=1 'init' "" = "" [OK] 1 simple "foo" = "foo" [OK] 2 string "foo" = "foo" [OK] 3 number "1234" = "1234" [OK] 4 negnumber "-1234" = "-1234" [OK] 5 unsigned "12345" = "12345" [OK] 6 char "c" = "c" [OK] 7 hex "f" = "f" [OK] 8 pointer "0x1" = "0x1" [OK] Errors during this test: 0 If this test result is ok for you, here is my: Tested-by: Zhangjin Wu <falcon@tinylab.org> Best regards, Zhangjin > > The memfd_create() syscall, enabled by CONFIG_MEMFD_CREATE, is useful on > its own even when not required by CONFIG_TMPFS or CONFIG_HUGETLBFS. > > 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@weissschuh.net> > --- > fs/Kconfig | 5 ++--- > mm/Kconfig | 3 +++ > 2 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/fs/Kconfig b/fs/Kconfig > index 18d034ec7953..19975b104bc3 100644 > --- a/fs/Kconfig > +++ b/fs/Kconfig > @@ -169,6 +169,7 @@ source "fs/sysfs/Kconfig" > config TMPFS > bool "Tmpfs virtual memory file system support (former shm fs)" > depends on SHMEM > + select MEMFD_CREATE > help > Tmpfs is a file system which keeps all files in virtual memory. > > @@ -240,6 +241,7 @@ config HUGETLBFS > bool "HugeTLB file system support" > depends on X86 || IA64 || SPARC64 || ARCH_SUPPORTS_HUGETLBFS || BROKEN > depends on (SYSFS || SYSCTL) > + select MEMFD_CREATE > help > hugetlbfs is a filesystem backing for HugeTLB pages, based on > ramfs. For architectures that support it, say Y here and read > @@ -264,9 +266,6 @@ config HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON > enable HVO by default. It can be disabled via hugetlb_free_vmemmap=off > (boot command line) or hugetlb_optimize_vmemmap (sysctl). > > -config MEMFD_CREATE > - def_bool TMPFS || HUGETLBFS > - > config ARCH_HAS_GIGANTIC_PAGE > bool > > diff --git a/mm/Kconfig b/mm/Kconfig > index 09130434e30d..22acffd9009d 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -1144,6 +1144,9 @@ config KMAP_LOCAL_NON_LINEAR_PTE_ARRAY > config IO_MAPPING > bool > > +config MEMFD_CREATE > + bool "Enable memfd_create() system call" if EXPERT > + > config SECRETMEM > default y > bool "Enable memfd_secret() system call" if EXPERT > > --- > base-commit: e55e5df193d247a38a5e1ac65a5316a0adcc22fa > change-id: 20230629-config-memfd-be6af03b7dca > > Best regards, > -- > Thomas Weißschuh <linux@weissschuh.net> >
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? (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@weissschuh.net> > --- > fs/Kconfig | 5 ++--- > mm/Kconfig | 3 +++ > 2 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/fs/Kconfig b/fs/Kconfig > index 18d034ec7953..19975b104bc3 100644 > --- a/fs/Kconfig > +++ b/fs/Kconfig > @@ -169,6 +169,7 @@ source "fs/sysfs/Kconfig" > config TMPFS > bool "Tmpfs virtual memory file system support (former shm fs)" > depends on SHMEM > + select MEMFD_CREATE > help > Tmpfs is a file system which keeps all files in virtual memory. > > @@ -240,6 +241,7 @@ config HUGETLBFS > bool "HugeTLB file system support" > depends on X86 || IA64 || SPARC64 || ARCH_SUPPORTS_HUGETLBFS || BROKEN > depends on (SYSFS || SYSCTL) > + select MEMFD_CREATE > help > hugetlbfs is a filesystem backing for HugeTLB pages, based on > ramfs. For architectures that support it, say Y here and read > @@ -264,9 +266,6 @@ config HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON > enable HVO by default. It can be disabled via hugetlb_free_vmemmap=off > (boot command line) or hugetlb_optimize_vmemmap (sysctl). > > -config MEMFD_CREATE > - def_bool TMPFS || HUGETLBFS > - > config ARCH_HAS_GIGANTIC_PAGE > bool > > diff --git a/mm/Kconfig b/mm/Kconfig > index 09130434e30d..22acffd9009d 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -1144,6 +1144,9 @@ config KMAP_LOCAL_NON_LINEAR_PTE_ARRAY > config IO_MAPPING > bool > > +config MEMFD_CREATE > + bool "Enable memfd_create() system call" if EXPERT > + > config SECRETMEM > default y > bool "Enable memfd_secret() system call" if EXPERT > > --- > base-commit: e55e5df193d247a38a5e1ac65a5316a0adcc22fa > change-id: 20230629-config-memfd-be6af03b7dca > > Best regards, > -- > Thomas Weißschuh <linux@weissschuh.net> >
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@weissschuh.net> > > --- > > fs/Kconfig | 5 ++--- > > mm/Kconfig | 3 +++ > > 2 files changed, 5 insertions(+), 3 deletions(-) > [..]
On 06/30/23 08:32, 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? > > (Not an objection, I'm just curious...) > It looks like shmem/tmpfs falls back to ramfs?
diff --git a/fs/Kconfig b/fs/Kconfig index 18d034ec7953..19975b104bc3 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -169,6 +169,7 @@ source "fs/sysfs/Kconfig" config TMPFS bool "Tmpfs virtual memory file system support (former shm fs)" depends on SHMEM + select MEMFD_CREATE help Tmpfs is a file system which keeps all files in virtual memory. @@ -240,6 +241,7 @@ config HUGETLBFS bool "HugeTLB file system support" depends on X86 || IA64 || SPARC64 || ARCH_SUPPORTS_HUGETLBFS || BROKEN depends on (SYSFS || SYSCTL) + select MEMFD_CREATE help hugetlbfs is a filesystem backing for HugeTLB pages, based on ramfs. For architectures that support it, say Y here and read @@ -264,9 +266,6 @@ config HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON enable HVO by default. It can be disabled via hugetlb_free_vmemmap=off (boot command line) or hugetlb_optimize_vmemmap (sysctl). -config MEMFD_CREATE - def_bool TMPFS || HUGETLBFS - config ARCH_HAS_GIGANTIC_PAGE bool diff --git a/mm/Kconfig b/mm/Kconfig index 09130434e30d..22acffd9009d 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1144,6 +1144,9 @@ config KMAP_LOCAL_NON_LINEAR_PTE_ARRAY config IO_MAPPING bool +config MEMFD_CREATE + bool "Enable memfd_create() system call" if EXPERT + config SECRETMEM default y bool "Enable memfd_secret() system call" if EXPERT