| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAOQ4uxjX8EcG5XssJ91u8Kn0gY9Rb0qCwnte_7j6Q6knvZ1shw@mail.gmail.com>
Date: Mon, 19 Jan 2026 17:41:16 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Jeff Layton <jlayton@...nel.org>
Cc: Christian Brauner <brauner@...nel.org>, Alexander Viro <viro@...iv.linux.org.uk>,
Chuck Lever <chuck.lever@...cle.com>, NeilBrown <neil@...wn.name>,
Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>,
Hugh Dickins <hughd@...gle.com>, Baolin Wang <baolin.wang@...ux.alibaba.com>,
Andrew Morton <akpm@...ux-foundation.org>, "Theodore Ts'o" <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>, Jan Kara <jack@...e.com>, Gao Xiang <xiang@...nel.org>,
Chao Yu <chao@...nel.org>, Yue Hu <zbestahu@...il.com>,
Jeffle Xu <jefflexu@...ux.alibaba.com>, Sandeep Dhavale <dhavale@...gle.com>,
Hongbo Li <lihongbo22@...wei.com>, Chunhai Guo <guochunhai@...o.com>,
Carlos Maiolino <cem@...nel.org>, Ilya Dryomov <idryomov@...il.com>, Alex Markuze <amarkuze@...hat.com>,
Viacheslav Dubeyko <slava@...eyko.com>, Chris Mason <clm@...com>, David Sterba <dsterba@...e.com>,
Luis de Bethencourt <luisbg@...nel.org>, Salah Triki <salah.triki@...il.com>,
Phillip Lougher <phillip@...ashfs.org.uk>, Steve French <sfrench@...ba.org>,
Paulo Alcantara <pc@...guebit.org>, Ronnie Sahlberg <ronniesahlberg@...il.com>,
Shyam Prasad N <sprasad@...rosoft.com>, Bharath SM <bharathsm@...rosoft.com>,
Miklos Szeredi <miklos@...redi.hu>, Mike Marshall <hubcap@...ibond.com>,
Martin Brandenburg <martin@...ibond.com>, Mark Fasheh <mark@...heh.com>, Joel Becker <jlbec@...lplan.org>,
Joseph Qi <joseph.qi@...ux.alibaba.com>,
Konstantin Komarov <almaz.alexandrovich@...agon-software.com>,
Ryusuke Konishi <konishi.ryusuke@...il.com>, Trond Myklebust <trondmy@...nel.org>,
Anna Schumaker <anna@...nel.org>, Dave Kleikamp <shaggy@...nel.org>,
David Woodhouse <dwmw2@...radead.org>, Richard Weinberger <richard@....at>, Jan Kara <jack@...e.cz>,
Andreas Gruenbacher <agruenba@...hat.com>, OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
Jaegeuk Kim <jaegeuk@...nel.org>, Jonathan Corbet <corbet@....net>,
David Laight <david.laight.linux@...il.com>, Dave Chinner <david@...morbit.com>,
Christoph Hellwig <hch@...radead.org>, linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, linux-ext4@...r.kernel.org,
linux-erofs@...ts.ozlabs.org, linux-xfs@...r.kernel.org,
ceph-devel@...r.kernel.org, linux-btrfs@...r.kernel.org,
linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
linux-unionfs@...r.kernel.org, devel@...ts.orangefs.org,
ocfs2-devel@...ts.linux.dev, ntfs3@...ts.linux.dev,
linux-nilfs@...r.kernel.org, jfs-discussion@...ts.sourceforge.net,
linux-mtd@...ts.infradead.org, gfs2@...ts.linux.dev,
linux-f2fs-devel@...ts.sourceforge.net, linux-doc@...r.kernel.org
Subject: Re: [PATCH v2 02/31] exportfs: add new EXPORT_OP_STABLE_HANDLES flag
On Mon, Jan 19, 2026 at 5:27 PM Jeff Layton <jlayton@...nel.org> wrote:
>
> At one time, nfsd could take the presence of struct export_operations to
> be an indicator that a filesystem was exportable via NFS. Since then, a
> lot of filesystems have grown export operations in order to provide
> filehandle support. Some of those (e.g. kernfs, pidfs, and nsfs) are not
> suitable for export via NFS since they lack filehandles that are
> stable across reboot.
>
> Add a new EXPORT_OP_STABLE_HANDLES flag that indicates that the
> filesystem supports perisistent filehandles,
persistent still here?
"...are stable across the lifetime of a file"?
> a requirement for nfs
> export. While in there, switch to the BIT() macro for defining these
> flags.
Maybe you want to move that cleanup to patch 1 along with the
export.rst sync? not a must.
>
> For now, the flag is not checked anywhere. That will come later after
> we've added it to the existing filesystems that need to remain
> exportable.
>
> Reviewed-by: Jan Kara <jack@...e.cz>
> Signed-off-by: Jeff Layton <jlayton@...nel.org>
> ---
> Documentation/filesystems/nfs/exporting.rst | 7 +++++++
> include/linux/exportfs.h | 16 +++++++++-------
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/filesystems/nfs/exporting.rst b/Documentation/filesystems/nfs/exporting.rst
> index 0583a0516b1e3a3e6a10af95ff88506cf02f7df4..0c29ee44e3484cef84d2d3d47819acf172d275a3 100644
> --- a/Documentation/filesystems/nfs/exporting.rst
> +++ b/Documentation/filesystems/nfs/exporting.rst
> @@ -244,3 +244,10 @@ following flags are defined:
> nfsd. A case in point is reexport of NFS itself, which can't be done
> safely without coordinating the grace period handling. Other clustered
> and networked filesystems can be problematic here as well.
> +
> + EXPORT_OP_STABLE_HANDLES - This filesystem provides filehandles that are
> + stable across the lifetime of a file. This is a hard requirement for export
> + via nfsd. Any filesystem that is eligible to be exported via nfsd must
> + indicate this guarantee by setting this flag. Most disk-based filesystems
> + can do this naturally. Pseudofilesystems that are for local reporting and
> + control (e.g. kernfs, pidfs, nsfs) usually can't support this.
> diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
> index f0cf2714ec52dd942b8f1c455a25702bd7e412b3..c4e0f083290e7e341342cf0b45b58fddda3af65e 100644
> --- a/include/linux/exportfs.h
> +++ b/include/linux/exportfs.h
> @@ -3,6 +3,7 @@
> #define LINUX_EXPORTFS_H 1
>
> #include <linux/types.h>
> +#include <linux/bits.h>
> #include <linux/path.h>
>
> struct dentry;
> @@ -277,15 +278,16 @@ struct export_operations {
> int nr_iomaps, struct iattr *iattr);
> int (*permission)(struct handle_to_path_ctx *ctx, unsigned int oflags);
> struct file * (*open)(const struct path *path, unsigned int oflags);
> -#define EXPORT_OP_NOWCC (0x1) /* don't collect v3 wcc data */
> -#define EXPORT_OP_NOSUBTREECHK (0x2) /* no subtree checking */
> -#define EXPORT_OP_CLOSE_BEFORE_UNLINK (0x4) /* close files before unlink */
> -#define EXPORT_OP_REMOTE_FS (0x8) /* Filesystem is remote */
> -#define EXPORT_OP_NOATOMIC_ATTR (0x10) /* Filesystem cannot supply
> +#define EXPORT_OP_NOWCC BIT(0) /* don't collect v3 wcc data */
> +#define EXPORT_OP_NOSUBTREECHK BIT(1) /* no subtree checking */
> +#define EXPORT_OP_CLOSE_BEFORE_UNLINK BIT(2) /* close files before unlink */
> +#define EXPORT_OP_REMOTE_FS BIT(3) /* Filesystem is remote */
> +#define EXPORT_OP_NOATOMIC_ATTR BIT(4) /* Filesystem cannot supply
> atomic attribute updates
> */
> -#define EXPORT_OP_FLUSH_ON_CLOSE (0x20) /* fs flushes file data on close */
> -#define EXPORT_OP_NOLOCKS (0x40) /* no file locking support */
> +#define EXPORT_OP_FLUSH_ON_CLOSE BIT(5) /* fs flushes file data on close */
> +#define EXPORT_OP_NOLOCKS BIT(6) /* no file locking support */
> +#define EXPORT_OP_STABLE_HANDLES BIT(7) /* fhs are stable across reboot */
> unsigned long flags;
> };
>
>
> --
> 2.52.0
>
Powered by blists - more mailing lists