From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F093C606A327 for ; Wed, 11 Nov 2026 21:17:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=fifzKJOw; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=JDSV52m4 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Cc:To:In-Reply-To:References :Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date: From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Unsubscribe-Post: List-Owner; bh=+PlyOtqsg4uvOLuXQ3/FL9HLYIT+WYfLjjBDzOseC4E=; b=fifzKJOwwKpkMD 42Pi7G/v9t7G/7Pf6OammJhNUeve8SyXFIWcItNkMaXzJKm2EpRBII/xagYIYi97jmlaRXzCIuSZm 9CTfItk/wEKEp7wF6MUvqUoA4mrgIWkSd9zmPoIskeuXw9rHEN8qV4NuUCapYc2kJcsvaOb6FFXON yVbiEzRIN7paXERPJN+zGDU5RtZjoUy7g0syqFn4bO9fzA1xhcRHc0VZIJZ9H+bLh7f1rpZyaXojA XFDc9ZzV4+PUNis6dXCYJkH4AnHN0ohIISjumZ0lOjPDQ3pf9WJjZg5ZFITsyKx+RTKd6/TKQ6TDr TZSaSKAi6JCNzjDwhgAw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xRFgm-00000007ill-2wdV; Wed, 11 Nov 2026 21:17:04 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xQhxp-00000003E3d-1gKK for linux-nvme@lists.infradead.org; Tue, 10 Nov 2026 09:16:27 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 2C96146A26; Tue, 10 Nov 2026 09:16:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C370A1F008BE; Tue, 10 Nov 2026 09:16:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794302185; bh=+PlyOtqsg4uvOLuXQ3/FL9HLYIT+WYfLjjBDzOseC4E=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=JDSV52m4OfCcyst3hFku2YCPCNxNeOvikciB89hDYJCR1LbwEEt/lYeTuQQD7/iUW H5tRIQ9v6jXMgiZgkJiF4GqOivkKtZZw7NCQaQ+f1NR7twZvTqcjqI+/c/IH9v/Jxy EoKQxUfmWpqjCJS9oAmdJNyKK7FKdWto+bebjhA+fYE+FkEqbaHlH+Oa9uQsiCi9GB 3VXoXUr7iZu5zDIGq4U4YgT3MCBnLcxw8LrsjsTPugWIr6zcD/ibPJDTK7P1rf/Nm/ FeXmWLksNQuP1ST2JEb6k4O48XmygmJ7cLGcrIfDn6Eu2LG0Vr4DLcJUZZqj6ewXS2 2mhb3DLeE7TVQ== From: Christian Brauner Date: Tue, 10 Nov 2026 10:14:20 +0100 Subject: [PATCH RFC 04/41] fs: add SB_I_PSEUDO X-Archived-By: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261110-work-loop-pseudo-v1-4-4c998976c6c7@kernel.org> References: <20261110-work-loop-pseudo-v1-0-4c998976c6c7@kernel.org> In-Reply-To: <20261110-work-loop-pseudo-v1-0-4c998976c6c7@kernel.org> To: linux-fsdevel@vger.kernel.org Cc: Jann Horn , Chris Mason , Josef Bacik , Christoph Hellwig , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, Alexander Viro , Jan Kara , linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, driver-core@lists.linux.dev, linux-mm@kvack.org, bpf@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, apparmor@lists.ubuntu.com, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, fuse-devel@lists.linux.dev, linux-efi@vger.kernel.org, xen-devel@lists.xenproject.org, ocfs2-devel@lists.linux.dev, linux-s390@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-usb@vger.kernel.org, Amir Goldstein , linux-erofs@lists.ozlabs.org, linux-kselftest@vger.kernel.org, "Christian Brauner (Amutable)" X-Mailer: b4 0.17-dev-ce4c1 X-Developer-Signature: v=1; a=openpgp-sha256; l=3427; i=brauner@kernel.org; h=from:subject:message-id; bh=k3b1S5Aks24kDoWnRvLqsdiiPcKIlG2bf4Gt1cYJbvU=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWR9ejDjkUK2x5tSpSe3sln+v7tvX2kk8yFWmKv/wMXyl fsivk7i6ShlYRDjYpAVU2RxaDcJl1vOU7HZKFMDZg4rE8gQBi5OAZjIgXSGn4zTcuXEC9Zcm34h e6vptpmiC3asPh6Q0BteemFfbSaHeDDDP+uZ7aUJ00OdGBbc/56893hNWHZRbjDHr99CTduPlCV M4wIA X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 X-Mailman-Approved-At: Wed, 11 Nov 2026 13:17:02 -0800 X-BeenThere: linux-nvme@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-nvme" X-Spam-Status: No, score=-18.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 Currently, there's no way to tell whether the files of a filesystem store data or whether they are kernel interfaces. Files on pseudo filesystems such as procfs or sysfs generate their contents when they're read and writes to them are commands to the kernel. But a few places in the kernel take an arbitrary file and use it as storage: loop, zloop, the nvme target's file backend, the scsi target's fileio backend, fuse passthrough, the usb mass storage gadget and erofs file-backed mounts. At most they check the file type and whether the file implements ->read_iter() and ->write_iter(). That's not enough. kernfs provides both for every sysfs attribute for example. Add SB_I_PSEUDO so a filesystem can state that its regular files are kernel interfaces and must not be used as storage. Pseudo filesystems also never hold executables or device nodes. But currently each of them decides on its own whether to raise SB_I_NOEXEC and SB_I_NODEV. Some do, most don't. Add fc_init_pseudo() as the common initialization point for all pseudo filesystems that raises all three flags and switch init_pseudo() over to it. The following patches convert the mountable pseudo filesystems. Nothing checks SB_I_PSEUDO yet so no functional changes. Signed-off-by: Christian Brauner (Amutable) --- fs/libfs.c | 2 +- include/linux/fs/super_types.h | 1 + include/linux/pseudo_fs.h | 11 +++++++++++ 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/fs/libfs.c b/fs/libfs.c index 96a6e9b1535f..8c8789489fdf 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -735,7 +735,7 @@ struct pseudo_fs_context *init_pseudo(struct fs_context *fc, fc->fs_private = ctx; fc->ops = &pseudo_fs_context_ops; fc->sb_flags |= SB_NOUSER; - fc->s_iflags |= SB_I_NOEXEC | SB_I_NODEV; + fc_init_pseudo(fc); fc->global = true; } return ctx; diff --git a/include/linux/fs/super_types.h b/include/linux/fs/super_types.h index 72f4288e16c5..472200bdf081 100644 --- a/include/linux/fs/super_types.h +++ b/include/linux/fs/super_types.h @@ -359,5 +359,6 @@ struct super_block { #define SB_I_NOIDMAP 0x00002000 /* No idmapped mounts on this superblock */ #define SB_I_ALLOW_HSM 0x00004000 /* Allow HSM events on this superblock */ #define SB_I_NO_DATA_INTEGRITY 0x00008000 /* fs cannot guarantee data persistence on sync */ +#define SB_I_PSEUDO 0x00010000 /* regular files are kernel interfaces, not storage */ #endif /* _LINUX_FS_SUPER_TYPES_H */ diff --git a/include/linux/pseudo_fs.h b/include/linux/pseudo_fs.h index a651e60d9410..0ca408aa60af 100644 --- a/include/linux/pseudo_fs.h +++ b/include/linux/pseudo_fs.h @@ -2,6 +2,7 @@ #define __LINUX_PSEUDO_FS__ #include +#include struct pseudo_fs_context { const struct super_operations *ops; @@ -15,4 +16,14 @@ struct pseudo_fs_context { struct pseudo_fs_context *init_pseudo(struct fs_context *fc, unsigned long magic); +/* + * Common initialization for all pseudo filesystems, mountable or not. Their + * regular files are kernel interfaces. They don't store data and pseudo + * filesystems never hold executables or device nodes. + */ +static inline void fc_init_pseudo(struct fs_context *fc) +{ + fc->s_iflags |= SB_I_PSEUDO | SB_I_NOEXEC | SB_I_NODEV; +} + #endif -- 2.53.0