[PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Jeff Layton]

In recent years, a number of filesystems that can't present stable
filehandles have grown struct export_operations. They've mostly done
this for local use-cases (enabling open_by_handle_at() and the like).
Unfortunately, having export_operations is generally sufficient to make
a filesystem be considered exportable via nfsd, but that requires that
the server present stable filehandles.

This patchset declares a new EXPORT_OP_STABLE_HANDLES flag, adds it to
all of the filesystems that have stable filehandles, and then adds a
check in nfsd to ensure that that flag is set for any filesystem to
which it has been presented a handle. When a filesystem doesn't have
this flag, it will treat the filehandle as stale.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
Jeff Layton (29):
      exportfs: add new EXPORT_OP_STABLE_HANDLES flag
      tmpfs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      ext4: add EXPORT_OP_STABLE_HANDLES flag to export operations
      ext2: add EXPORT_OP_STABLE_HANDLES flag to export operations
      erofs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      efs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      xfs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      ceph: add EXPORT_OP_STABLE_HANDLES flag to export operations
      btrfs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      befs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      ufs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      udf: add EXPORT_OP_STABLE_HANDLES flag to export operations
      affs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      squashfs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      smb/client: add EXPORT_OP_STABLE_HANDLES flag to export operations
      ovl: add EXPORT_OP_STABLE_HANDLES flag to export operations
      orangefs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      ocfs2: add EXPORT_OP_STABLE_HANDLES flag to export operations
      ntfs3: add EXPORT_OP_STABLE_HANDLES flag to export operations
      nilfs2: add EXPORT_OP_STABLE_HANDLES flag to export operations
      nfs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      jfs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      jffs2: add EXPORT_OP_STABLE_HANDLES flag to export operations
      isofs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      gfs2: add EXPORT_OP_STABLE_HANDLES flag to export operations
      fuse: add EXPORT_OP_STABLE_HANDLES flag to export operations
      fat: add EXPORT_OP_STABLE_HANDLES flag to export operations
      f2fs: add EXPORT_OP_STABLE_HANDLES flag to export operations
      nfsd: only allow filesystems that set EXPORT_OP_STABLE_HANDLES

 fs/affs/namei.c          |  1 +
 fs/befs/linuxvfs.c       |  1 +
 fs/btrfs/export.c        |  1 +
 fs/ceph/export.c         |  1 +
 fs/efs/super.c           |  1 +
 fs/erofs/super.c         |  1 +
 fs/ext2/super.c          |  1 +
 fs/ext4/super.c          |  1 +
 fs/f2fs/super.c          |  1 +
 fs/fat/nfs.c             |  2 ++
 fs/fuse/inode.c          |  2 ++
 fs/gfs2/export.c         |  1 +
 fs/isofs/export.c        |  1 +
 fs/jffs2/super.c         |  1 +
 fs/jfs/super.c           |  1 +
 fs/nfs/export.c          |  3 ++-
 fs/nfsd/nfsfh.c          |  4 ++++
 fs/nilfs2/namei.c        |  1 +
 fs/ntfs3/super.c         |  1 +
 fs/ocfs2/export.c        |  1 +
 fs/orangefs/super.c      |  1 +
 fs/overlayfs/export.c    |  2 ++
 fs/smb/client/export.c   |  1 +
 fs/squashfs/export.c     |  3 ++-
 fs/udf/namei.c           |  1 +
 fs/ufs/super.c           |  1 +
 fs/xfs/xfs_export.c      |  1 +
 include/linux/exportfs.h | 16 +++++++++-------
 mm/shmem.c               |  1 +
 29 files changed, 45 insertions(+), 9 deletions(-)
---
base-commit: c537e12daeecaecdcd322c56a5f70659d2de7bde
change-id: 20260114-exportfs-nfsd-12515072e9a9

Best regards,
-- 
Jeff Layton <jlayton@kernel.org>

[PATCH 01/29] exportfs: add new EXPORT_OP_STABLE_HANDLES flag

[Jeff Layton]

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, a requirement for nfs
export. While in there, switch to the BIT() macro for defining these
flags.

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.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 include/linux/exportfs.h | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
index f0cf2714ec52dd942b8f1c455a25702bd7e412b3..159b679ef176dc710e9d0107ff9315534c44f715 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) /* required for nfsd export */
 	unsigned long	flags;
 };
 

-- 
2.52.0

Re: [PATCH 01/29] exportfs: add new EXPORT_OP_STABLE_HANDLES flag

[Jan Kara]

On Thu 15-01-26 12:47:32, Jeff Layton 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, a requirement for nfs
> export. While in there, switch to the BIT() macro for defining these
> flags.
> 
> 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.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

...

> -#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) /* required for nfsd export */

The comment "required for nfsd export" doesn't quite match the name. I'd
change the comment to something like "file handles are stable across
reboot". Otherwise feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[PATCH 02/29] tmpfs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to tmpfs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 mm/shmem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/shmem.c b/mm/shmem.c
index ec6c01378e9d2bd47db9d7506e4d6a565e092185..c64c4410b4fd9961599a5ea768b469d8184e713e 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -4477,6 +4477,7 @@ static const struct export_operations shmem_export_ops = {
 	.get_parent     = shmem_get_parent,
 	.encode_fh      = shmem_encode_fh,
 	.fh_to_dentry	= shmem_fh_to_dentry,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };
 
 enum shmem_param {

-- 
2.52.0

Re: [PATCH 02/29] tmpfs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jan Kara]

On Thu 15-01-26 12:47:33, Jeff Layton wrote:
> Add the EXPORT_OP_STABLE_HANDLES flag to tmpfs export operations to indicate
> that this filesystem can be exported via NFS.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

Looks good. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  mm/shmem.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/shmem.c b/mm/shmem.c
> index ec6c01378e9d2bd47db9d7506e4d6a565e092185..c64c4410b4fd9961599a5ea768b469d8184e713e 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -4477,6 +4477,7 @@ static const struct export_operations shmem_export_ops = {
>  	.get_parent     = shmem_get_parent,
>  	.encode_fh      = shmem_encode_fh,
>  	.fh_to_dentry	= shmem_fh_to_dentry,
> +	.flags		= EXPORT_OP_STABLE_HANDLES,
>  };
>  
>  enum shmem_param {
> 
> -- 
> 2.52.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[PATCH 03/29] ext4: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to ext4 export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/ext4/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 87205660c5d026c3a73a64788757c288a03eaa5f..09b4c4bb8e559da087ec957de3115e4f7d450923 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1651,6 +1651,7 @@ static const struct export_operations ext4_export_ops = {
 	.fh_to_parent = ext4_fh_to_parent,
 	.get_parent = ext4_get_parent,
 	.commit_metadata = ext4_nfs_commit_metadata,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };
 
 enum {

-- 
2.52.0

Re: [PATCH 03/29] ext4: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Theodore Tso]

On Thu, Jan 15, 2026 at 12:47:34PM -0500, Jeff Layton wrote:
> Add the EXPORT_OP_STABLE_HANDLES flag to ext4 export operations to indicate
> that this filesystem can be exported via NFS.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

Acked-by: Theodore Ts'o <tytso@mit.edu>

Re: [PATCH 03/29] ext4: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jan Kara]

On Thu 15-01-26 12:47:34, Jeff Layton wrote:
> Add the EXPORT_OP_STABLE_HANDLES flag to ext4 export operations to indicate
> that this filesystem can be exported via NFS.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

Looks good. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/ext4/super.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 87205660c5d026c3a73a64788757c288a03eaa5f..09b4c4bb8e559da087ec957de3115e4f7d450923 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1651,6 +1651,7 @@ static const struct export_operations ext4_export_ops = {
>  	.fh_to_parent = ext4_fh_to_parent,
>  	.get_parent = ext4_get_parent,
>  	.commit_metadata = ext4_nfs_commit_metadata,
> +	.flags = EXPORT_OP_STABLE_HANDLES,
>  };
>  
>  enum {
> 
> -- 
> 2.52.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[PATCH 04/29] ext2: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to ext2 export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/ext2/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index 121e634c792ab625d7a07251e572e5844242fc2a..936675f06806d268ded5a3ba5306575c437ca9ce 100644
--- a/fs/ext2/super.c
+++ b/fs/ext2/super.c
@@ -426,6 +426,7 @@ static const struct export_operations ext2_export_ops = {
 	.fh_to_dentry = ext2_fh_to_dentry,
 	.fh_to_parent = ext2_fh_to_parent,
 	.get_parent = ext2_get_parent,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };
 
 enum {

-- 
2.52.0

Re: [PATCH 04/29] ext2: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jan Kara]

On Thu 15-01-26 12:47:35, Jeff Layton wrote:
> Add the EXPORT_OP_STABLE_HANDLES flag to ext2 export operations to indicate
> that this filesystem can be exported via NFS.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

Looks good. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/ext2/super.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/ext2/super.c b/fs/ext2/super.c
> index 121e634c792ab625d7a07251e572e5844242fc2a..936675f06806d268ded5a3ba5306575c437ca9ce 100644
> --- a/fs/ext2/super.c
> +++ b/fs/ext2/super.c
> @@ -426,6 +426,7 @@ static const struct export_operations ext2_export_ops = {
>  	.fh_to_dentry = ext2_fh_to_dentry,
>  	.fh_to_parent = ext2_fh_to_parent,
>  	.get_parent = ext2_get_parent,
> +	.flags = EXPORT_OP_STABLE_HANDLES,
>  };
>  
>  enum {
> 
> -- 
> 2.52.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[PATCH 05/29] erofs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to erofs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/erofs/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/erofs/super.c b/fs/erofs/super.c
index 5136cda5972a986dece863290d20ab103791cb98..7b43ad2dd3eada8c132b26f851394492dfe4bfe3 100644
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@ -608,6 +608,7 @@ static const struct export_operations erofs_export_ops = {
 	.fh_to_dentry = erofs_fh_to_dentry,
 	.fh_to_parent = erofs_fh_to_parent,
 	.get_parent = erofs_get_parent,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };
 
 static void erofs_set_sysfs_name(struct super_block *sb)

-- 
2.52.0

[PATCH 06/29] efs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to efs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/efs/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/efs/super.c b/fs/efs/super.c
index c59086b7eabfe93939d06f36826aa91838e41ba2..5e06acdab03b6f30bfa469e48463cb0e8a3b32a1 100644
--- a/fs/efs/super.c
+++ b/fs/efs/super.c
@@ -115,6 +115,7 @@ static const struct export_operations efs_export_ops = {
 	.fh_to_dentry	= efs_fh_to_dentry,
 	.fh_to_parent	= efs_fh_to_parent,
 	.get_parent	= efs_get_parent,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };
 
 static int __init init_efs_fs(void) {

-- 
2.52.0

[PATCH 07/29] xfs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to xfs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/xfs/xfs_export.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/xfs/xfs_export.c b/fs/xfs/xfs_export.c
index 201489d3de0899af34f0485e00fb8b36842d419d..1be2de3394841a2960c1b2791897067b83cc7763 100644
--- a/fs/xfs/xfs_export.c
+++ b/fs/xfs/xfs_export.c
@@ -248,4 +248,5 @@ const struct export_operations xfs_export_operations = {
 	.map_blocks		= xfs_fs_map_blocks,
 	.commit_blocks		= xfs_fs_commit_blocks,
 #endif
+	.flags			= EXPORT_OP_STABLE_HANDLES,
 };

-- 
2.52.0

[PATCH 08/29] ceph: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to ceph export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/ceph/export.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ceph/export.c b/fs/ceph/export.c
index b2f2af1046791d8423c91b79556bde384a2fe627..10104d20f736a8092ed847ecb27030be286c0ede 100644
--- a/fs/ceph/export.c
+++ b/fs/ceph/export.c
@@ -615,4 +615,5 @@ const struct export_operations ceph_export_ops = {
 	.fh_to_parent = ceph_fh_to_parent,
 	.get_parent = ceph_get_parent,
 	.get_name = ceph_get_name,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };

-- 
2.52.0

Re: [PATCH 08/29] ceph: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Viacheslav Dubeyko]

On Thu, 2026-01-15 at 12:47 -0500, Jeff Layton wrote:
> Add the EXPORT_OP_STABLE_HANDLES flag to ceph export operations to indicate
> that this filesystem can be exported via NFS.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
>  fs/ceph/export.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/ceph/export.c b/fs/ceph/export.c
> index b2f2af1046791d8423c91b79556bde384a2fe627..10104d20f736a8092ed847ecb27030be286c0ede 100644
> --- a/fs/ceph/export.c
> +++ b/fs/ceph/export.c
> @@ -615,4 +615,5 @@ const struct export_operations ceph_export_ops = {
>  	.fh_to_parent = ceph_fh_to_parent,
>  	.get_parent = ceph_get_parent,
>  	.get_name = ceph_get_name,
> +	.flags = EXPORT_OP_STABLE_HANDLES,
>  };

Looks good.

Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>

Thanks,
Slava.

[PATCH 09/29] btrfs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to btrfs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/btrfs/export.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/btrfs/export.c b/fs/btrfs/export.c
index 230d9326b685c4e12dc0fffd4a86ebba68a55bd6..14b688849ce406b2f784015afced2c29422ab6c3 100644
--- a/fs/btrfs/export.c
+++ b/fs/btrfs/export.c
@@ -304,4 +304,5 @@ const struct export_operations btrfs_export_ops = {
 	.fh_to_parent	= btrfs_fh_to_parent,
 	.get_parent	= btrfs_get_parent,
 	.get_name	= btrfs_get_name,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };

-- 
2.52.0

[PATCH 10/29] befs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to befs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/befs/linuxvfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c
index 9fcfdd6b8189aaf5cc3b68aa8dff4798af5bdcbc..1f358d58af8b4de9bc840b9926970340395bc9e4 100644
--- a/fs/befs/linuxvfs.c
+++ b/fs/befs/linuxvfs.c
@@ -99,6 +99,7 @@ static const struct export_operations befs_export_operations = {
 	.fh_to_dentry	= befs_fh_to_dentry,
 	.fh_to_parent	= befs_fh_to_parent,
 	.get_parent	= befs_get_parent,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };
 
 /*

-- 
2.52.0

[PATCH 11/29] ufs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to ufs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/ufs/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ufs/super.c b/fs/ufs/super.c
index 6e4585169f94bb9652aac29a14b0a64a7bb710d8..9cd9b6691849d52701058973f6b684f101df2634 100644
--- a/fs/ufs/super.c
+++ b/fs/ufs/super.c
@@ -141,6 +141,7 @@ static const struct export_operations ufs_export_ops = {
 	.fh_to_dentry	= ufs_fh_to_dentry,
 	.fh_to_parent	= ufs_fh_to_parent,
 	.get_parent	= ufs_get_parent,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };
 
 #ifdef CONFIG_UFS_DEBUG

-- 
2.52.0

[PATCH 12/29] udf: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to udf export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/udf/namei.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/udf/namei.c b/fs/udf/namei.c
index 5f2e9a892bffa9579143cedf71d80efa7ad6e9fb..7b8db8331c77bb43d9a3c4528aee535eac2bbd37 100644
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -1012,6 +1012,7 @@ const struct export_operations udf_export_ops = {
 	.fh_to_dentry   = udf_fh_to_dentry,
 	.fh_to_parent   = udf_fh_to_parent,
 	.get_parent     = udf_get_parent,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };
 
 const struct inode_operations udf_dir_inode_operations = {

-- 
2.52.0

Re: [PATCH 12/29] udf: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jan Kara]

On Thu 15-01-26 12:47:43, Jeff Layton wrote:
> Add the EXPORT_OP_STABLE_HANDLES flag to udf export operations to indicate
> that this filesystem can be exported via NFS.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

Looks good. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/udf/namei.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/udf/namei.c b/fs/udf/namei.c
> index 5f2e9a892bffa9579143cedf71d80efa7ad6e9fb..7b8db8331c77bb43d9a3c4528aee535eac2bbd37 100644
> --- a/fs/udf/namei.c
> +++ b/fs/udf/namei.c
> @@ -1012,6 +1012,7 @@ const struct export_operations udf_export_ops = {
>  	.fh_to_dentry   = udf_fh_to_dentry,
>  	.fh_to_parent   = udf_fh_to_parent,
>  	.get_parent     = udf_get_parent,
> +	.flags		= EXPORT_OP_STABLE_HANDLES,
>  };
>  
>  const struct inode_operations udf_dir_inode_operations = {
> 
> -- 
> 2.52.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[PATCH 13/29] affs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to affs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/affs/namei.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/affs/namei.c b/fs/affs/namei.c
index f883be50db122d3b09f0ae4d24618bd49b55186b..edea4d868b5131fa69912655879231912ceff168 100644
--- a/fs/affs/namei.c
+++ b/fs/affs/namei.c
@@ -569,6 +569,7 @@ const struct export_operations affs_export_ops = {
 	.fh_to_dentry = affs_fh_to_dentry,
 	.fh_to_parent = affs_fh_to_parent,
 	.get_parent = affs_get_parent,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };
 
 const struct dentry_operations affs_dentry_operations = {

-- 
2.52.0

[PATCH 14/29] squashfs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to squashfs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/squashfs/export.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/squashfs/export.c b/fs/squashfs/export.c
index 62972f0ff8681c798f0b11e17d501373b2145bd9..c6c4d8f1f115c65b6dac29582bb5b447b823d3b8 100644
--- a/fs/squashfs/export.c
+++ b/fs/squashfs/export.c
@@ -176,5 +176,6 @@ const struct export_operations squashfs_export_ops = {
 	.encode_fh = generic_encode_ino32_fh,
 	.fh_to_dentry = squashfs_fh_to_dentry,
 	.fh_to_parent = squashfs_fh_to_parent,
-	.get_parent = squashfs_get_parent
+	.get_parent = squashfs_get_parent,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };

-- 
2.52.0

[PATCH 15/29] smb/client: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to cifs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/smb/client/export.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/smb/client/export.c b/fs/smb/client/export.c
index d606e8cbcb7db2b4026675bd9cbc264834687807..c1c23e21bfe610f1b5bf8d0eea64ab49e2c6ee3a 100644
--- a/fs/smb/client/export.c
+++ b/fs/smb/client/export.c
@@ -47,6 +47,7 @@ const struct export_operations cifs_export_ops = {
  * Following export operations are mandatory for NFS export support:
  *	.fh_to_dentry =
  */
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };
 
 #endif /* CONFIG_CIFS_NFSD_EXPORT */

-- 
2.52.0

Re: [PATCH 15/29] smb/client: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Amir Goldstein]

On Thu, Jan 15, 2026 at 6:49 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> Add the EXPORT_OP_STABLE_HANDLES flag to cifs export operations to indicate
> that this filesystem can be exported via NFS.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
>  fs/smb/client/export.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/fs/smb/client/export.c b/fs/smb/client/export.c
> index d606e8cbcb7db2b4026675bd9cbc264834687807..c1c23e21bfe610f1b5bf8d0eea64ab49e2c6ee3a 100644
> --- a/fs/smb/client/export.c
> +++ b/fs/smb/client/export.c
> @@ -47,6 +47,7 @@ const struct export_operations cifs_export_ops = {
>   * Following export operations are mandatory for NFS export support:
>   *     .fh_to_dentry =
>   */
> +       .flags = EXPORT_OP_STABLE_HANDLES,

Kind of odd to have this here after the comment out of NFS export.
Maybe add it inside the comment...

Thanks,
Amir.

[PATCH 16/29] ovl: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to overlayfs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/overlayfs/export.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/overlayfs/export.c b/fs/overlayfs/export.c
index 83f80fdb156749e65a4ea0ab708cbff338dacdad..17c92a228120e1803135cc2b4fe4180f5e343f88 100644
--- a/fs/overlayfs/export.c
+++ b/fs/overlayfs/export.c
@@ -865,9 +865,11 @@ const struct export_operations ovl_export_operations = {
 	.fh_to_parent	= ovl_fh_to_parent,
 	.get_name	= ovl_get_name,
 	.get_parent	= ovl_get_parent,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };
 
 /* encode_fh() encodes non-decodable file handles with nfs_export=off */
 const struct export_operations ovl_export_fid_operations = {
 	.encode_fh	= ovl_encode_fh,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };

-- 
2.52.0

Re: [PATCH 16/29] ovl: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Amir Goldstein]

On Thu, Jan 15, 2026 at 6:49 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> Add the EXPORT_OP_STABLE_HANDLES flag to overlayfs export operations to indicate
> that this filesystem can be exported via NFS.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
>  fs/overlayfs/export.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/fs/overlayfs/export.c b/fs/overlayfs/export.c
> index 83f80fdb156749e65a4ea0ab708cbff338dacdad..17c92a228120e1803135cc2b4fe4180f5e343f88 100644
> --- a/fs/overlayfs/export.c
> +++ b/fs/overlayfs/export.c
> @@ -865,9 +865,11 @@ const struct export_operations ovl_export_operations = {
>         .fh_to_parent   = ovl_fh_to_parent,
>         .get_name       = ovl_get_name,
>         .get_parent     = ovl_get_parent,
> +       .flags          = EXPORT_OP_STABLE_HANDLES,
>  };
>
>  /* encode_fh() encodes non-decodable file handles with nfs_export=off */
>  const struct export_operations ovl_export_fid_operations = {
>         .encode_fh      = ovl_encode_fh,
> +       .flags          = EXPORT_OP_STABLE_HANDLES,
>  };
>

Actually, see comment above:
/* encode_fh() encodes non-decodable file handles with nfs_export=off */

That's the variant of export_ops when overlayfs cannot be nfs exported
because its encoded file handles can change after copyup+reboot.

Thanks,
Amir.

[PATCH 17/29] orangefs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to orangefs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/orangefs/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/orangefs/super.c b/fs/orangefs/super.c
index b46100a4f5293576549300ae9050430c3f07969b..140f27f750939cf5538eb68501dd60012bd2daec 100644
--- a/fs/orangefs/super.c
+++ b/fs/orangefs/super.c
@@ -377,6 +377,7 @@ static int orangefs_encode_fh(struct inode *inode,
 static const struct export_operations orangefs_export_ops = {
 	.encode_fh = orangefs_encode_fh,
 	.fh_to_dentry = orangefs_fh_to_dentry,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };
 
 static int orangefs_unmount(int id, __s32 fs_id, const char *devname)

-- 
2.52.0

[PATCH 18/29] ocfs2: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to ocfs2 export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/ocfs2/export.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ocfs2/export.c b/fs/ocfs2/export.c
index b95724b767e150e991ae4b8ea5d0505c1ae95984..77d82ff994c86037c14fbf7a1d9706f1dd2b87ac 100644
--- a/fs/ocfs2/export.c
+++ b/fs/ocfs2/export.c
@@ -280,4 +280,5 @@ const struct export_operations ocfs2_export_ops = {
 	.fh_to_dentry	= ocfs2_fh_to_dentry,
 	.fh_to_parent	= ocfs2_fh_to_parent,
 	.get_parent	= ocfs2_get_parent,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };

-- 
2.52.0

Re: [PATCH 18/29] ocfs2: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jan Kara]

On Thu 15-01-26 12:47:49, Jeff Layton wrote:
> Add the EXPORT_OP_STABLE_HANDLES flag to ocfs2 export operations to indicate
> that this filesystem can be exported via NFS.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

Looks good. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/ocfs2/export.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/ocfs2/export.c b/fs/ocfs2/export.c
> index b95724b767e150e991ae4b8ea5d0505c1ae95984..77d82ff994c86037c14fbf7a1d9706f1dd2b87ac 100644
> --- a/fs/ocfs2/export.c
> +++ b/fs/ocfs2/export.c
> @@ -280,4 +280,5 @@ const struct export_operations ocfs2_export_ops = {
>  	.fh_to_dentry	= ocfs2_fh_to_dentry,
>  	.fh_to_parent	= ocfs2_fh_to_parent,
>  	.get_parent	= ocfs2_get_parent,
> +	.flags		= EXPORT_OP_STABLE_HANDLES,
>  };
> 
> -- 
> 2.52.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[PATCH 19/29] ntfs3: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to ntfs3 export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/ntfs3/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ntfs3/super.c b/fs/ntfs3/super.c
index 8b0cf0ed4f72cc643b2b42fc491b259cf19fe3b8..df58aeb46206982cc782fad6005a13160806926d 100644
--- a/fs/ntfs3/super.c
+++ b/fs/ntfs3/super.c
@@ -889,6 +889,7 @@ static const struct export_operations ntfs_export_ops = {
 	.fh_to_parent = ntfs_fh_to_parent,
 	.get_parent = ntfs3_get_parent,
 	.commit_metadata = ntfs_nfs_commit_metadata,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };
 
 /*

-- 
2.52.0

[PATCH 20/29] nilfs2: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to nilfs2 export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/nilfs2/namei.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/nilfs2/namei.c b/fs/nilfs2/namei.c
index 40f4b1a28705b6e0eb8f0978cf3ac18b43aa1331..975123586d1b1703e25ba6dd3117f397b3d785c1 100644
--- a/fs/nilfs2/namei.c
+++ b/fs/nilfs2/namei.c
@@ -591,4 +591,5 @@ const struct export_operations nilfs_export_ops = {
 	.fh_to_dentry = nilfs_fh_to_dentry,
 	.fh_to_parent = nilfs_fh_to_parent,
 	.get_parent = nilfs_get_parent,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };

-- 
2.52.0

Re: [PATCH 20/29] nilfs2: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Ryusuke Konishi]

On Fri, Jan 16, 2026 at 2:50 AM Jeff Layton wrote:
>
> Add the EXPORT_OP_STABLE_HANDLES flag to nilfs2 export operations to indicate
> that this filesystem can be exported via NFS.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

Acked-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>

Thanks,
Ryusuke Konishi

[PATCH 21/29] nfs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to nfs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/nfs/export.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/export.c b/fs/nfs/export.c
index a10dd5f9d0786eb111113bf524a1af8b7da0fb6e..7592ef347a2eae5d6305b64effd22537d5ef5e74 100644
--- a/fs/nfs/export.c
+++ b/fs/nfs/export.c
@@ -162,5 +162,6 @@ const struct export_operations nfs_export_ops = {
 		 EXPORT_OP_REMOTE_FS		|
 		 EXPORT_OP_NOATOMIC_ATTR	|
 		 EXPORT_OP_FLUSH_ON_CLOSE	|
-		 EXPORT_OP_NOLOCKS,
+		 EXPORT_OP_NOLOCKS		|
+		 EXPORT_OP_STABLE_HANDLES,
 };

-- 
2.52.0

[PATCH 22/29] jfs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to jfs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/jfs/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/jfs/super.c b/fs/jfs/super.c
index 3cfb86c5a36e8f0c46a2734a24fba6ffd36c7ad9..ac9b6d754f8c203baa7e91362aeb0dc9b3ce209f 100644
--- a/fs/jfs/super.c
+++ b/fs/jfs/super.c
@@ -864,6 +864,7 @@ static const struct export_operations jfs_export_operations = {
 	.fh_to_dentry	= jfs_fh_to_dentry,
 	.fh_to_parent	= jfs_fh_to_parent,
 	.get_parent	= jfs_get_parent,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };
 
 static void jfs_init_options(struct fs_context *fc, struct jfs_context *ctx)

-- 
2.52.0

Re: [PATCH 22/29] jfs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Dave Kleikamp]

On 1/15/26 11:47AM, Jeff Layton wrote:
> Add the EXPORT_OP_STABLE_HANDLES flag to jfs export operations to indicate
> that this filesystem can be exported via NFS.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com>

> ---
>   fs/jfs/super.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/fs/jfs/super.c b/fs/jfs/super.c
> index 3cfb86c5a36e8f0c46a2734a24fba6ffd36c7ad9..ac9b6d754f8c203baa7e91362aeb0dc9b3ce209f 100644
> --- a/fs/jfs/super.c
> +++ b/fs/jfs/super.c
> @@ -864,6 +864,7 @@ static const struct export_operations jfs_export_operations = {
>   	.fh_to_dentry	= jfs_fh_to_dentry,
>   	.fh_to_parent	= jfs_fh_to_parent,
>   	.get_parent	= jfs_get_parent,
> +	.flags		= EXPORT_OP_STABLE_HANDLES,
>   };
>   
>   static void jfs_init_options(struct fs_context *fc, struct jfs_context *ctx)
> 

[PATCH 23/29] jffs2: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to jffs2 export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/jffs2/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 4545f885c41efa1d925afc1d643576d859c42921..80ff5a0130603f94c9bce452c976753c85314c3a 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -155,6 +155,7 @@ static const struct export_operations jffs2_export_ops = {
 	.get_parent = jffs2_get_parent,
 	.fh_to_dentry = jffs2_fh_to_dentry,
 	.fh_to_parent = jffs2_fh_to_parent,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };
 
 /*

-- 
2.52.0

Re: [PATCH 23/29] jffs2: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Add the EXPORT_OP_STABLE_HANDLES flag to jffs2 export operations to indicate
> that this filesystem can be exported via NFS.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/jffs2/super.c | 1 +
> 1 file changed, 1 insertion(+)

Acked-by: Richard Weinberger <richard@nod.at>

Thanks,
//richard

[PATCH 24/29] isofs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to isofs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/isofs/export.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/isofs/export.c b/fs/isofs/export.c
index 421d247fae52301b778f0589b27fcf48f2372832..7c17eb4e030813d1d22456ccbfb005c6b6934500 100644
--- a/fs/isofs/export.c
+++ b/fs/isofs/export.c
@@ -190,4 +190,5 @@ const struct export_operations isofs_export_ops = {
 	.fh_to_dentry	= isofs_fh_to_dentry,
 	.fh_to_parent	= isofs_fh_to_parent,
 	.get_parent     = isofs_export_get_parent,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };

-- 
2.52.0

Re: [PATCH 24/29] isofs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jan Kara]

On Thu 15-01-26 12:47:55, Jeff Layton wrote:
> Add the EXPORT_OP_STABLE_HANDLES flag to isofs export operations to indicate
> that this filesystem can be exported via NFS.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

Looks good. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/isofs/export.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/isofs/export.c b/fs/isofs/export.c
> index 421d247fae52301b778f0589b27fcf48f2372832..7c17eb4e030813d1d22456ccbfb005c6b6934500 100644
> --- a/fs/isofs/export.c
> +++ b/fs/isofs/export.c
> @@ -190,4 +190,5 @@ const struct export_operations isofs_export_ops = {
>  	.fh_to_dentry	= isofs_fh_to_dentry,
>  	.fh_to_parent	= isofs_fh_to_parent,
>  	.get_parent     = isofs_export_get_parent,
> +	.flags		= EXPORT_OP_STABLE_HANDLES,
>  };
> 
> -- 
> 2.52.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[PATCH 25/29] gfs2: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to gfs2 export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/gfs2/export.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/gfs2/export.c b/fs/gfs2/export.c
index 3334c394ce9cbe26969809874a94e79bf068b11b..43fd2203b34fb0894d2b71e50278e5cd68216ce7 100644
--- a/fs/gfs2/export.c
+++ b/fs/gfs2/export.c
@@ -190,5 +190,6 @@ const struct export_operations gfs2_export_ops = {
 	.fh_to_parent = gfs2_fh_to_parent,
 	.get_name = gfs2_get_name,
 	.get_parent = gfs2_get_parent,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };
 

-- 
2.52.0

[PATCH 26/29] fuse: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to fuse export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/fuse/inode.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index 819e50d666224a6201cfc7f450e0bd37bfe32810..1652a98db639fd75e8201b681a29c68b4eab093c 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -1208,6 +1208,7 @@ static struct dentry *fuse_get_parent(struct dentry *child)
 /* only for fid encoding; no support for file handle */
 static const struct export_operations fuse_export_fid_operations = {
 	.encode_fh	= fuse_encode_fh,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };
 
 static const struct export_operations fuse_export_operations = {
@@ -1215,6 +1216,7 @@ static const struct export_operations fuse_export_operations = {
 	.fh_to_parent	= fuse_fh_to_parent,
 	.encode_fh	= fuse_encode_fh,
 	.get_parent	= fuse_get_parent,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };
 
 static const struct super_operations fuse_super_operations = {

-- 
2.52.0

Re: [PATCH 26/29] fuse: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Amir Goldstein]

On Thu, Jan 15, 2026 at 6:50 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> Add the EXPORT_OP_STABLE_HANDLES flag to fuse export operations to indicate
> that this filesystem can be exported via NFS.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
>  fs/fuse/inode.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index 819e50d666224a6201cfc7f450e0bd37bfe32810..1652a98db639fd75e8201b681a29c68b4eab093c 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -1208,6 +1208,7 @@ static struct dentry *fuse_get_parent(struct dentry *child)
>  /* only for fid encoding; no support for file handle */
>  static const struct export_operations fuse_export_fid_operations = {
>         .encode_fh      = fuse_encode_fh,
> +       .flags          = EXPORT_OP_STABLE_HANDLES,
>  };

These are used when the server declares FUSE_NO_EXPORT_SUPPORT
so do not opt in for NFS export.

The sad thing w.r.t FUSE is that in most likelihood server does not provide
persistent handles also when it does not declare FUSE_NO_EXPORT_SUPPORT
but we are stuck with that.

Thanks,
Amir.

Re: [PATCH 26/29] fuse: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

On Thu, 2026-01-15 at 19:54 +0100, Amir Goldstein wrote:
> On Thu, Jan 15, 2026 at 6:50 PM Jeff Layton <jlayton@kernel.org> wrote:
> > 
> > Add the EXPORT_OP_STABLE_HANDLES flag to fuse export operations to indicate
> > that this filesystem can be exported via NFS.
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> >  fs/fuse/inode.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> > index 819e50d666224a6201cfc7f450e0bd37bfe32810..1652a98db639fd75e8201b681a29c68b4eab093c 100644
> > --- a/fs/fuse/inode.c
> > +++ b/fs/fuse/inode.c
> > @@ -1208,6 +1208,7 @@ static struct dentry *fuse_get_parent(struct dentry *child)
> >  /* only for fid encoding; no support for file handle */
> >  static const struct export_operations fuse_export_fid_operations = {
> >         .encode_fh      = fuse_encode_fh,
> > +       .flags          = EXPORT_OP_STABLE_HANDLES,
> >  };
> 
> These are used when the server declares FUSE_NO_EXPORT_SUPPORT
> so do not opt in for NFS export.
> 
> The sad thing w.r.t FUSE is that in most likelihood server does not provide
> persistent handles also when it does not declare FUSE_NO_EXPORT_SUPPORT
> but we are stuck with that.
> 
> Thanks,
> Amir.

Thanks, I removed that flag in the patch in my tree.

-- 
Jeff Layton <jlayton@kernel.org>

[PATCH 27/29] fat: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to fat export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/fat/nfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/fat/nfs.c b/fs/fat/nfs.c
index 509eea96a457d41f63f04480da32aceae75a8a4a..f6a5c8c4f5e8a14e549b5aad6643d490f1d062b1 100644
--- a/fs/fat/nfs.c
+++ b/fs/fat/nfs.c
@@ -289,6 +289,7 @@ const struct export_operations fat_export_ops = {
 	.fh_to_dentry   = fat_fh_to_dentry,
 	.fh_to_parent   = fat_fh_to_parent,
 	.get_parent     = fat_get_parent,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };
 
 const struct export_operations fat_export_ops_nostale = {
@@ -296,4 +297,5 @@ const struct export_operations fat_export_ops_nostale = {
 	.fh_to_dentry   = fat_fh_to_dentry_nostale,
 	.fh_to_parent   = fat_fh_to_parent_nostale,
 	.get_parent     = fat_get_parent,
+	.flags		= EXPORT_OP_STABLE_HANDLES,
 };

-- 
2.52.0

[PATCH 28/29] f2fs: add EXPORT_OP_STABLE_HANDLES flag to export operations

[Jeff Layton]

Add the EXPORT_OP_STABLE_HANDLES flag to f2fs export operations to indicate
that this filesystem can be exported via NFS.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/f2fs/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index c4c225e09dc4701f009dec4338f2eaba1820ea7d..260c26771c431bbb36e99be8daff6cde40662751 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -3750,6 +3750,7 @@ static const struct export_operations f2fs_export_ops = {
 	.fh_to_dentry = f2fs_fh_to_dentry,
 	.fh_to_parent = f2fs_fh_to_parent,
 	.get_parent = f2fs_get_parent,
+	.flags = EXPORT_OP_STABLE_HANDLES,
 };
 
 loff_t max_file_blocks(struct inode *inode)

-- 
2.52.0

[PATCH 29/29] nfsd: only allow filesystems that set EXPORT_OP_STABLE_HANDLES

[Jeff Layton]

Some filesystems have grown export operations in order to provide
filehandles for local usage. Some of these filesystems are unsuitable
for use with nfsd, since their filehandles are not persistent across
reboots.

In __fh_verify, check whether EXPORT_OP_STABLE_HANDLES is set
and return nfserr_stale if it isn't.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/nfsd/nfsfh.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
index ed85dd43da18e6d4c4667ff14dc035f2eacff1d6..da9d5fb2e6613c2707195da2e8678b3fcb3d444d 100644
--- a/fs/nfsd/nfsfh.c
+++ b/fs/nfsd/nfsfh.c
@@ -334,6 +334,10 @@ __fh_verify(struct svc_rqst *rqstp,
 	dentry = fhp->fh_dentry;
 	exp = fhp->fh_export;
 
+	error = nfserr_stale;
+	if (!(dentry->d_sb->s_export_op->flags & EXPORT_OP_STABLE_HANDLES))
+		goto out;
+
 	trace_nfsd_fh_verify(rqstp, fhp, type, access);
 
 	/*

-- 
2.52.0

Re: [PATCH 29/29] nfsd: only allow filesystems that set EXPORT_OP_STABLE_HANDLES

[Amir Goldstein]

On Thu, Jan 15, 2026 at 6:51 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> Some filesystems have grown export operations in order to provide
> filehandles for local usage. Some of these filesystems are unsuitable
> for use with nfsd, since their filehandles are not persistent across
> reboots.
>
> In __fh_verify, check whether EXPORT_OP_STABLE_HANDLES is set
> and return nfserr_stale if it isn't.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
>  fs/nfsd/nfsfh.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> index ed85dd43da18e6d4c4667ff14dc035f2eacff1d6..da9d5fb2e6613c2707195da2e8678b3fcb3d444d 100644
> --- a/fs/nfsd/nfsfh.c
> +++ b/fs/nfsd/nfsfh.c
> @@ -334,6 +334,10 @@ __fh_verify(struct svc_rqst *rqstp,
>         dentry = fhp->fh_dentry;
>         exp = fhp->fh_export;
>
> +       error = nfserr_stale;
> +       if (!(dentry->d_sb->s_export_op->flags & EXPORT_OP_STABLE_HANDLES))
> +               goto out;
> +
>         trace_nfsd_fh_verify(rqstp, fhp, type, access);
>

IDGI. Don't you want  to deny the export of those fs in check_export()?
By the same logic that check_export() checks for can_decode_fh()
not for can_encode_fh().

Thanks,
Amir.

Re: [PATCH 29/29] nfsd: only allow filesystems that set EXPORT_OP_STABLE_HANDLES

[Jeff Layton]

On Thu, 2026-01-15 at 20:23 +0100, Amir Goldstein wrote:
> On Thu, Jan 15, 2026 at 6:51 PM Jeff Layton <jlayton@kernel.org> wrote:
> > 
> > Some filesystems have grown export operations in order to provide
> > filehandles for local usage. Some of these filesystems are unsuitable
> > for use with nfsd, since their filehandles are not persistent across
> > reboots.
> > 
> > In __fh_verify, check whether EXPORT_OP_STABLE_HANDLES is set
> > and return nfserr_stale if it isn't.
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> >  fs/nfsd/nfsfh.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> > index ed85dd43da18e6d4c4667ff14dc035f2eacff1d6..da9d5fb2e6613c2707195da2e8678b3fcb3d444d 100644
> > --- a/fs/nfsd/nfsfh.c
> > +++ b/fs/nfsd/nfsfh.c
> > @@ -334,6 +334,10 @@ __fh_verify(struct svc_rqst *rqstp,
> >         dentry = fhp->fh_dentry;
> >         exp = fhp->fh_export;
> > 
> > +       error = nfserr_stale;
> > +       if (!(dentry->d_sb->s_export_op->flags & EXPORT_OP_STABLE_HANDLES))
> > +               goto out;
> > +
> >         trace_nfsd_fh_verify(rqstp, fhp, type, access);
> > 
> 
> IDGI. Don't you want  to deny the export of those fs in check_export()?
> By the same logic that check_export() checks for can_decode_fh()
> not for can_encode_fh().
> 

It certainly won't hurt to add a check for this to check_export(), and
I've gone ahead and done so. To be clear, doing that won't prevent the
filesystem from being exported, but you will get a warning like this
when you try:

    exportfs: /sys/fs/cgroup does not support NFS export

That export will still show up in mountd though, so this is just a
warning. Trying to mount it though will fail.

Thanks,
-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH 29/29] nfsd: only allow filesystems that set EXPORT_OP_STABLE_HANDLES

[Amir Goldstein]

On Fri, Jan 16, 2026 at 1:36 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> On Thu, 2026-01-15 at 20:23 +0100, Amir Goldstein wrote:
> > On Thu, Jan 15, 2026 at 6:51 PM Jeff Layton <jlayton@kernel.org> wrote:
> > >
> > > Some filesystems have grown export operations in order to provide
> > > filehandles for local usage. Some of these filesystems are unsuitable
> > > for use with nfsd, since their filehandles are not persistent across
> > > reboots.
> > >
> > > In __fh_verify, check whether EXPORT_OP_STABLE_HANDLES is set
> > > and return nfserr_stale if it isn't.
> > >
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > ---
> > >  fs/nfsd/nfsfh.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> > > index ed85dd43da18e6d4c4667ff14dc035f2eacff1d6..da9d5fb2e6613c2707195da2e8678b3fcb3d444d 100644
> > > --- a/fs/nfsd/nfsfh.c
> > > +++ b/fs/nfsd/nfsfh.c
> > > @@ -334,6 +334,10 @@ __fh_verify(struct svc_rqst *rqstp,
> > >         dentry = fhp->fh_dentry;
> > >         exp = fhp->fh_export;
> > >
> > > +       error = nfserr_stale;
> > > +       if (!(dentry->d_sb->s_export_op->flags & EXPORT_OP_STABLE_HANDLES))
> > > +               goto out;
> > > +
> > >         trace_nfsd_fh_verify(rqstp, fhp, type, access);
> > >
> >
> > IDGI. Don't you want  to deny the export of those fs in check_export()?
> > By the same logic that check_export() checks for can_decode_fh()
> > not for can_encode_fh().
> >
>
> It certainly won't hurt to add a check for this to check_export(), and
> I've gone ahead and done so. To be clear, doing that won't prevent the
> filesystem from being exported, but you will get a warning like this
> when you try:
>
>     exportfs: /sys/fs/cgroup does not support NFS export
>
> That export will still show up in mountd though, so this is just a
> warning. Trying to mount it though will fail.
>

Oh, I did not know. What an odd user experience.
Anyway, better than no warning at all.

Thanks,
Amir.

Re: [PATCH 29/29] nfsd: only allow filesystems that set EXPORT_OP_STABLE_HANDLES

[Jeff Layton]

On Fri, 2026-01-16 at 15:46 +0100, Amir Goldstein wrote:
> On Fri, Jan 16, 2026 at 1:36 PM Jeff Layton <jlayton@kernel.org> wrote:
> > 
> > On Thu, 2026-01-15 at 20:23 +0100, Amir Goldstein wrote:
> > > On Thu, Jan 15, 2026 at 6:51 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > > 
> > > > Some filesystems have grown export operations in order to provide
> > > > filehandles for local usage. Some of these filesystems are unsuitable
> > > > for use with nfsd, since their filehandles are not persistent across
> > > > reboots.
> > > > 
> > > > In __fh_verify, check whether EXPORT_OP_STABLE_HANDLES is set
> > > > and return nfserr_stale if it isn't.
> > > > 
> > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > ---
> > > >  fs/nfsd/nfsfh.c | 4 ++++
> > > >  1 file changed, 4 insertions(+)
> > > > 
> > > > diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> > > > index ed85dd43da18e6d4c4667ff14dc035f2eacff1d6..da9d5fb2e6613c2707195da2e8678b3fcb3d444d 100644
> > > > --- a/fs/nfsd/nfsfh.c
> > > > +++ b/fs/nfsd/nfsfh.c
> > > > @@ -334,6 +334,10 @@ __fh_verify(struct svc_rqst *rqstp,
> > > >         dentry = fhp->fh_dentry;
> > > >         exp = fhp->fh_export;
> > > > 
> > > > +       error = nfserr_stale;
> > > > +       if (!(dentry->d_sb->s_export_op->flags & EXPORT_OP_STABLE_HANDLES))
> > > > +               goto out;
> > > > +
> > > >         trace_nfsd_fh_verify(rqstp, fhp, type, access);
> > > > 
> > > 
> > > IDGI. Don't you want  to deny the export of those fs in check_export()?
> > > By the same logic that check_export() checks for can_decode_fh()
> > > not for can_encode_fh().
> > > 
> > 
> > It certainly won't hurt to add a check for this to check_export(), and
> > I've gone ahead and done so. To be clear, doing that won't prevent the
> > filesystem from being exported, but you will get a warning like this
> > when you try:
> > 
> >     exportfs: /sys/fs/cgroup does not support NFS export
> > 
> > That export will still show up in mountd though, so this is just a
> > warning. Trying to mount it though will fail.
> > 
> 
> Oh, I did not know. What an odd user experience.
> Anyway, better than no warning at all.
> 

Indeed.

The catch is that this won't catch all scenarios where that fs could be
exported. If you do something like this in /etc/exports:

     /	*(rw,crossmnt,insecure,no_root_squash)

...you won't see a warning. Granted, doing the above is _dumb_ but it
illustrates that it's not possible to completely vet the export table.
Even if you could, it could change out from under you.

We do have some ideas about updating the export management, but nothing
concrete yet. Even then, we'll need to maintain backward compatibility,
so I doubt we can change the user experience in a fundamental way at
this point.
-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Amir Goldstein]

On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> In recent years, a number of filesystems that can't present stable
> filehandles have grown struct export_operations. They've mostly done
> this for local use-cases (enabling open_by_handle_at() and the like).
> Unfortunately, having export_operations is generally sufficient to make
> a filesystem be considered exportable via nfsd, but that requires that
> the server present stable filehandles.

Where does the term "stable file handles" come from? and what does it mean?
Why not "persistent handles", which is described in NFS and SMB specs?

Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
by both Christoph and Christian:

https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/

Am I missing anything?

Thanks,
Amir.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Jeff Layton]

On Thu, 2026-01-15 at 19:17 +0100, Amir Goldstein wrote:
> On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@kernel.org> wrote:
> > 
> > In recent years, a number of filesystems that can't present stable
> > filehandles have grown struct export_operations. They've mostly done
> > this for local use-cases (enabling open_by_handle_at() and the like).
> > Unfortunately, having export_operations is generally sufficient to make
> > a filesystem be considered exportable via nfsd, but that requires that
> > the server present stable filehandles.
> 
> Where does the term "stable file handles" come from? and what does it mean?
> Why not "persistent handles", which is described in NFS and SMB specs?
> 
> Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
> by both Christoph and Christian:
> 
> https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/
> 
> Am I missing anything?
> 

This was Chuck's suggested name. His point was that STABLE means that
the FH's don't change during the lifetime of the file.

I don't much care about the flag name, so if everyone likes PERSISTENT
better I'll roll with that.

Also, on the ovl patch: will fix...

Thanks for the review!
-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[NeilBrown]

On Fri, 16 Jan 2026, Jeff Layton wrote:
> On Thu, 2026-01-15 at 19:17 +0100, Amir Goldstein wrote:
> > On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > 
> > > In recent years, a number of filesystems that can't present stable
> > > filehandles have grown struct export_operations. They've mostly done
> > > this for local use-cases (enabling open_by_handle_at() and the like).
> > > Unfortunately, having export_operations is generally sufficient to make
> > > a filesystem be considered exportable via nfsd, but that requires that
> > > the server present stable filehandles.
> > 
> > Where does the term "stable file handles" come from? and what does it mean?
> > Why not "persistent handles", which is described in NFS and SMB specs?
> > 
> > Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
> > by both Christoph and Christian:
> > 
> > https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/
> > 
> > Am I missing anything?
> > 
> 
> This was Chuck's suggested name. His point was that STABLE means that
> the FH's don't change during the lifetime of the file.
> 
> I don't much care about the flag name, so if everyone likes PERSISTENT
> better I'll roll with that.

I don't like PERSISTENT.
I'd rather call a spade a spade.

  EXPORT_OP_SUPPORTS_NFS_EXPORT
or
  EXPORT_OP_NOT_NFS_COMPATIBLE

The issue here is NFS export and indirection doesn't bring any benefits.

NeilBrown


> 
> Also, on the ovl patch: will fix...
> 
> Thanks for the review!
> -- 
> Jeff Layton <jlayton@kernel.org>
> 

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christoph Hellwig]

On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > This was Chuck's suggested name. His point was that STABLE means that
> > the FH's don't change during the lifetime of the file.
> > 
> > I don't much care about the flag name, so if everyone likes PERSISTENT
> > better I'll roll with that.
> 
> I don't like PERSISTENT.
> I'd rather call a spade a spade.
> 
>   EXPORT_OP_SUPPORTS_NFS_EXPORT
> or
>   EXPORT_OP_NOT_NFS_COMPATIBLE
> 
> The issue here is NFS export and indirection doesn't bring any benefits.

No, it absolutely is not.  And the whole concept of calling something
after the initial or main use is a recipe for a mess.

Pick a name that conveys what the flag is about, and document those
semantics well.  This flag is about the fact that for a given file,
as long as that file exists in the file system the handle is stable.
Both stable and persistent are suitable for that, nfs is everything
but.

Remember nfs also support volatile file handles, and other applications
might rely on this (I know of quite a few user space applications that
do, but they are kinda hardwired to xfs anyway).

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[NeilBrown]

On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > This was Chuck's suggested name. His point was that STABLE means that
> > > the FH's don't change during the lifetime of the file.
> > > 
> > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > better I'll roll with that.
> > 
> > I don't like PERSISTENT.
> > I'd rather call a spade a spade.
> > 
> >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > or
> >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > 
> > The issue here is NFS export and indirection doesn't bring any benefits.
> 
> No, it absolutely is not.  And the whole concept of calling something
> after the initial or main use is a recipe for a mess.

We are calling it for it's only use.  If there was ever another use, we
could change the name if that made sense.  It is not a public name, it
is easy to change.

> 
> Pick a name that conveys what the flag is about, and document those
> semantics well.  This flag is about the fact that for a given file,
> as long as that file exists in the file system the handle is stable.
> Both stable and persistent are suitable for that, nfs is everything
> but.

My understanding is that kernfs would not get the flag.
kernfs filehandles do not change as long as the file exist.
But this is not sufficient for the files to be usefully exported.

I suspect kernfs does re-use filehandles relatively soon after the
file/object has been destroyed.  Maybe that is the real problem here:
filehandle reuse, not filehandle stability.

Jeff: could you please give details (and preserve them in future cover
letters) of which filesystems are known to have problems and what
exactly those problems are?

> 
> Remember nfs also support volatile file handles, and other applications
> might rely on this (I know of quite a few user space applications that
> do, but they are kinda hardwired to xfs anyway).

The NFS protocol supports volatile file handles.  knfsd does not.
So maybe
  EXPORT_OP_NOT_NFSD_COMPATIBLE
might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
(I prefer opt-out rather than opt-in because nfsd export was the
original purpose of export_operations, but it isn't something
I would fight for)

NeilBrown

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christoph Hellwig]

On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote:
> We are calling it for it's only use.  If there was ever another use, we
> could change the name if that made sense.  It is not a public name, it
> is easy to change.

No, it is not the only use.  This flag needs to be propagate to
userspace through statx or the file attrs.  As I said before there
is plenty of code in userspace that does rely on the traditional
file handle semantics.

> > Remember nfs also support volatile file handles, and other applications
> > might rely on this (I know of quite a few user space applications that
> > do, but they are kinda hardwired to xfs anyway).
> 
> The NFS protocol supports volatile file handles.  knfsd does not.
> So maybe
>   EXPORT_OP_NOT_NFSD_COMPATIBLE
> might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> (I prefer opt-out rather than opt-in because nfsd export was the
> original purpose of export_operations, but it isn't something
> I would fight for)

Again, stop trying to name things of the initial user.  Flag needs to
describe smenatics, not users.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christian Brauner]

On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote:
> On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> > On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > > This was Chuck's suggested name. His point was that STABLE means that
> > > > the FH's don't change during the lifetime of the file.
> > > > 
> > > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > > better I'll roll with that.
> > > 
> > > I don't like PERSISTENT.
> > > I'd rather call a spade a spade.
> > > 
> > >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > > or
> > >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > > 
> > > The issue here is NFS export and indirection doesn't bring any benefits.
> > 
> > No, it absolutely is not.  And the whole concept of calling something
> > after the initial or main use is a recipe for a mess.
> 
> We are calling it for it's only use.  If there was ever another use, we
> could change the name if that made sense.  It is not a public name, it
> is easy to change.
> 
> > 
> > Pick a name that conveys what the flag is about, and document those
> > semantics well.  This flag is about the fact that for a given file,
> > as long as that file exists in the file system the handle is stable.
> > Both stable and persistent are suitable for that, nfs is everything
> > but.
> 
> My understanding is that kernfs would not get the flag.
> kernfs filehandles do not change as long as the file exist.
> But this is not sufficient for the files to be usefully exported.
> 
> I suspect kernfs does re-use filehandles relatively soon after the
> file/object has been destroyed.  Maybe that is the real problem here:
> filehandle reuse, not filehandle stability.
> 
> Jeff: could you please give details (and preserve them in future cover
> letters) of which filesystems are known to have problems and what
> exactly those problems are?
> 
> > 
> > Remember nfs also support volatile file handles, and other applications
> > might rely on this (I know of quite a few user space applications that
> > do, but they are kinda hardwired to xfs anyway).
> 
> The NFS protocol supports volatile file handles.  knfsd does not.
> So maybe
>   EXPORT_OP_NOT_NFSD_COMPATIBLE
> might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> (I prefer opt-out rather than opt-in because nfsd export was the
> original purpose of export_operations, but it isn't something
> I would fight for)

I prefer one of the variants you proposed here but I don't particularly
care. It's not a hill worth dying on. So if Christoph insists on the
other name then I say let's just go with it.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[NeilBrown]

On Mon, 19 Jan 2026, Christian Brauner wrote:
> On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote:
> > On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> > > On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > > > This was Chuck's suggested name. His point was that STABLE means that
> > > > > the FH's don't change during the lifetime of the file.
> > > > > 
> > > > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > > > better I'll roll with that.
> > > > 
> > > > I don't like PERSISTENT.
> > > > I'd rather call a spade a spade.
> > > > 
> > > >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > > > or
> > > >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > > > 
> > > > The issue here is NFS export and indirection doesn't bring any benefits.
> > > 
> > > No, it absolutely is not.  And the whole concept of calling something
> > > after the initial or main use is a recipe for a mess.
> > 
> > We are calling it for it's only use.  If there was ever another use, we
> > could change the name if that made sense.  It is not a public name, it
> > is easy to change.
> > 
> > > 
> > > Pick a name that conveys what the flag is about, and document those
> > > semantics well.  This flag is about the fact that for a given file,
> > > as long as that file exists in the file system the handle is stable.
> > > Both stable and persistent are suitable for that, nfs is everything
> > > but.
> > 
> > My understanding is that kernfs would not get the flag.
> > kernfs filehandles do not change as long as the file exist.
> > But this is not sufficient for the files to be usefully exported.
> > 
> > I suspect kernfs does re-use filehandles relatively soon after the
> > file/object has been destroyed.  Maybe that is the real problem here:
> > filehandle reuse, not filehandle stability.
> > 
> > Jeff: could you please give details (and preserve them in future cover
> > letters) of which filesystems are known to have problems and what
> > exactly those problems are?
> > 
> > > 
> > > Remember nfs also support volatile file handles, and other applications
> > > might rely on this (I know of quite a few user space applications that
> > > do, but they are kinda hardwired to xfs anyway).
> > 
> > The NFS protocol supports volatile file handles.  knfsd does not.
> > So maybe
> >   EXPORT_OP_NOT_NFSD_COMPATIBLE
> > might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> > (I prefer opt-out rather than opt-in because nfsd export was the
> > original purpose of export_operations, but it isn't something
> > I would fight for)
> 
> I prefer one of the variants you proposed here but I don't particularly
> care. It's not a hill worth dying on. So if Christoph insists on the
> other name then I say let's just go with it.
> 

This sounds like you are recommending that we give in to bullying.
I would rather the decision be made based on the facts of the case, not
the opinions that are stated most bluntly.

I actually think that what Christoph wants is actually quite different
from what Jeff wants, and maybe two flags are needed.  But I don't yet
have a clear understanding of what Christoph wants, so I cannot be sure.

NeilBrown

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christoph Hellwig]

On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> This sounds like you are recommending that we give in to bullying.

I find your suggestion that anything you disagree with is bullying
extremely offensive.  If you have valid reasons for naming something
after the user instead of explaining the semantics, please explain that.

If you think NFS actually explains the semantics pretty well, please
explain that too, especially in forms that can be put into
documentation, including for the user ABI.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[NeilBrown]

On Tue, 20 Jan 2026, Christoph Hellwig wrote:
> On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> > This sounds like you are recommending that we give in to bullying.
> 
> I find your suggestion that anything you disagree with is bullying
> extremely offensive.  If you have valid reasons for naming something
> after the user instead of explaining the semantics, please explain that.

I was referring not to your behaviour but to this statement by Christian:

  So if Christoph insists on the other name then I say let's just go with it.

I think that someone "insisting" on something rather than "arguing
rationally" for something "sounds like" bullying.  Had Christian said
something like "Christoph has convinced me of the wisdom of his choice"
that would have been very different.

I am quite happy to have reasoned discussions with people who disagree
with me.  I hope to always provide new relevant information, and hope
they will too.

> 
> If you think NFS actually explains the semantics pretty well, please
> explain that too, especially in forms that can be put into
> documentation, including for the user ABI.

There are multiple issues here:

 - filehandle stability.  As far as I know all filesystems provide
   stable filehandles when the "subtree_check" export option is not used.
   Certainly cgroupfs does.  So having an EXPORT_OP_STABLE_HANDLES
   flag would mean it was set for every filesystem - unless there is
   something else I'm not aware of.  That is certainly possible and I
   hope someone will let me know if I'm missing something.

 - filehandle uniqueness.  This is somewhat important and if a
   filesystem doesn't provide it, that should be considered a bug.  In a
   different thread Christian has observed that there would be benefit
   if pidfs and nsfs provided uniqueness across reboots.  It is quite
   easy for a virtual filesystem to generate a 64 bit random number when
   the fs is initialised, and include that in file handles.  Having a
   EXPORT_OP_REUSES_HANDLES flag could mark filesystems that are still
   buggy if that is thought to be useful.

 - GETATTR always reporting file size of 0.  This is the only concrete
   symptom that Jeff has reported (that I have seen).  This  makes it
   impossible to read files over NFS even if they have content.
   Would EXPORT_OP_INACCURATE_SIZE be useful?

 - maintainer feature choice.  A maintainer may choose not to support
   export over NFS because they feel that there is no value and the
   possible support burden would not be worth it.  There may be locking
   / lease / etc issues that further complicate things.  So it might be
   reasonable for a maintainer to choose to forbid NFS export while
   allowing local fhandle access. EXPORT_OP_NO_NFS_EXPORT.

It took me a while to sift through the code/patches/comments and come to
this understanding and I apologise if I wasn't as clear earlier.  But
my intuition was always that file handle stability was never the real
issue, and maintainer choice was.  Hence my rejection of the
"STABLE_HANDLES" name.

Thanks,
NeilBrown

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christian Brauner]

> It took me a while to sift through the code/patches/comments and come to
> this understanding and I apologise if I wasn't as clear earlier.  But
> my intuition was always that file handle stability was never the real
> issue, and maintainer choice was.  Hence my rejection of the

I very much agree with that assessment. Yet we so far have failed to
even agree that this is an acceptable position. Hence my irritation.

And apologies on my part if I'm curt. I'm simply annoyed by the very
lengthy and to me somewhat pointless debate here at times.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christoph Hellwig]

On Tue, Jan 20, 2026 at 08:27:46PM +1100, NeilBrown wrote:
> > If you think NFS actually explains the semantics pretty well, please
> > explain that too, especially in forms that can be put into
> > documentation, including for the user ABI.
> 
> There are multiple issues here:
> 
>  - filehandle stability.  As far as I know all filesystems provide
>    stable filehandles when the "subtree_check" export option is not used.

That is news to me, but certainly interesting.  Does this include not
reusing the file handle for a new incarnation of the same thing?

>    Certainly cgroupfs does.  So having an EXPORT_OP_STABLE_HANDLES
>    flag would mean it was set for every filesystem - unless there is
>    something else I'm not aware of.  That is certainly possible and I
>    hope someone will let me know if I'm missing something.

Well, if does not provide stable file handles with the subtree_check
export option, or more importantly with the CONNECTABLE flag passed
to encode_fh, which is the level we're operating on, it can't set the
flag.

>  - filehandle uniqueness.  This is somewhat important and if a
>    filesystem doesn't provide it, that should be considered a bug.  In a
>    different thread Christian has observed that there would be benefit
>    if pidfs and nsfs provided uniqueness across reboots.  It is quite
>    easy for a virtual filesystem to generate a 64 bit random number when
>    the fs is initialised, and include that in file handles.  Having a
>    EXPORT_OP_REUSES_HANDLES flag could mark filesystems that are still
>    buggy if that is thought to be useful.

Yes.

>  - GETATTR always reporting file size of 0.  This is the only concrete
>    symptom that Jeff has reported (that I have seen).  This  makes it
>    impossible to read files over NFS even if they have content.
>    Would EXPORT_OP_INACCURATE_SIZE be useful?

i_size = 0 for a regular file sounds like a genuine bug to me.  I'm
actually surprised anything works with that.

>  - maintainer feature choice.  A maintainer may choose not to support
>    export over NFS because they feel that there is no value and the
>    possible support burden would not be worth it.

The maintainer has no way to disallow exporting through nfs.  They can
at best disallow exporting using the kernel nfs daemon if we provide
that facility.  But as I've argued multiple times, making arbitrary,
selective and very narrow choices about use cases without technical
backing for them (which then would be expressable as a flag like those
listed by you above) is really bad software development practice, and
not something that we usually do in the Linux kernel.

>    There may be locking
>    / lease / etc issues that further complicate things.  So it might be
>    reasonable for a maintainer to choose to forbid NFS export while
>    allowing local fhandle access. EXPORT_OP_NO_NFS_EXPORT.

We already have a EXPORT_OP_NOLOCKS flag to deal with this.

> 
> It took me a while to sift through the code/patches/comments and come to
> this understanding and I apologise if I wasn't as clear earlier.  But
> my intuition was always that file handle stability was never the real
> issue, and maintainer choice was.  Hence my rejection of the
> "STABLE_HANDLES" name.

Why do you keep ignoring the fat that the stable handles are really
important for anyone wanting to actually use them for their original
storage purpose, be that for knfsd, a userland nfs damon, or other
storage applications in userspace despite explaining this countless
times?

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[NeilBrown]

On Wed, 21 Jan 2026, Christoph Hellwig wrote:
> On Tue, Jan 20, 2026 at 08:27:46PM +1100, NeilBrown wrote:
> > > If you think NFS actually explains the semantics pretty well, please
> > > explain that too, especially in forms that can be put into
> > > documentation, including for the user ABI.
> > 
> > There are multiple issues here:
> > 
> >  - filehandle stability.  As far as I know all filesystems provide
> >    stable filehandles when the "subtree_check" export option is not used.
> 
> That is news to me, but certainly interesting.  Does this include not
> reusing the file handle for a new incarnation of the same thing?

"stable" and "reuse" are quite distinct concepts in my mind.
"a new incarnation of the same thing" is in my experience a new thing.
  rmdir foo: mkdir foo
on an empty directory will create a new incarnation of the same thing.
But it will appear to be different in various ways.

Names, not file handles, are generally used for new incarnations of the
same thing (again - in my experience).

I cannot 100% guarantee that all fs's provide filehandle stability, but
I am not aware of any, and none have been presented in this discussion.

It is true that the NFSv4 spec claims to allow them but I find the
details provided insufficient.
They might be able to work reliably if the server provided a delegation, but
without it I don't think they can be used reliably.  I'm certainly not
aware of any attempt to support them in Linux client or server.
(I know Trond doesn't like "connectable" file handles).

> 
> >    Certainly cgroupfs does.  So having an EXPORT_OP_STABLE_HANDLES
> >    flag would mean it was set for every filesystem - unless there is
> >    something else I'm not aware of.  That is certainly possible and I
> >    hope someone will let me know if I'm missing something.
> 
> Well, if does not provide stable file handles with the subtree_check
> export option, or more importantly with the CONNECTABLE flag passed
> to encode_fh, which is the level we're operating on, it can't set the
> flag.
> 

Hmmm...  I didn't know that open_by_handle_at() supported CONNECTABLE
requests. That seems relatively recent.

If CONNECTABLE is requested, then only directories get stable
filehandles.
If CONNECTABLE is not requested, then all filehandles should be stable.



> >  - filehandle uniqueness.  This is somewhat important and if a
> >    filesystem doesn't provide it, that should be considered a bug.  In a
> >    different thread Christian has observed that there would be benefit
> >    if pidfs and nsfs provided uniqueness across reboots.  It is quite
> >    easy for a virtual filesystem to generate a 64 bit random number when
> >    the fs is initialised, and include that in file handles.  Having a
> >    EXPORT_OP_REUSES_HANDLES flag could mark filesystems that are still
> >    buggy if that is thought to be useful.
> 
> Yes.
> 
> >  - GETATTR always reporting file size of 0.  This is the only concrete
> >    symptom that Jeff has reported (that I have seen).  This  makes it
> >    impossible to read files over NFS even if they have content.
> >    Would EXPORT_OP_INACCURATE_SIZE be useful?
> 
> i_size = 0 for a regular file sounds like a genuine bug to me.  I'm
> actually surprised anything works with that.

Files in /proc are all size zero.
Files in /sys seem to be all 4096 (or maybe PAGE_SIZE).
Files in /sys/kernel/security are all size zero
Files in /sys/fs/cgroup are all zero

I agree it is weird, but it seems to work ...  though I do have a vague
memory of something not working because it used a library function to
read a file, and it needed to be fixed.  No details come to mind except
that it was probably md related.

As some of these virtual files can be different every time they are
read, there is TOCTOU issue with trying to make the i_size accurately
reflect the result of a subsequent read.  I think the cost of setting an
accurate i_size even when it is possible is not seen as worth while.

> 
> >  - maintainer feature choice.  A maintainer may choose not to support
> >    export over NFS because they feel that there is no value and the
> >    possible support burden would not be worth it.
> 
> The maintainer has no way to disallow exporting through nfs.  They can
> at best disallow exporting using the kernel nfs daemon if we provide
> that facility.  But as I've argued multiple times, making arbitrary,
> selective and very narrow choices about use cases without technical
> backing for them (which then would be expressable as a flag like those
> listed by you above) is really bad software development practice, and
> not something that we usually do in the Linux kernel.

True: once you make files available to people you cannot control what
people will do with them.
So maybe you are saying "what is so special about knfsd that it gets
information that no-one else can get".  I cannot argue against that.

> 
> >    There may be locking
> >    / lease / etc issues that further complicate things.  So it might be
> >    reasonable for a maintainer to choose to forbid NFS export while
> >    allowing local fhandle access. EXPORT_OP_NO_NFS_EXPORT.
> 
> We already have a EXPORT_OP_NOLOCKS flag to deal with this.
> 
> > 
> > It took me a while to sift through the code/patches/comments and come to
> > this understanding and I apologise if I wasn't as clear earlier.  But
> > my intuition was always that file handle stability was never the real
> > issue, and maintainer choice was.  Hence my rejection of the
> > "STABLE_HANDLES" name.
> 
> Why do you keep ignoring the fat that the stable handles are really
> important for anyone wanting to actually use them for their original
> storage purpose, be that for knfsd, a userland nfs damon, or other
> storage applications in userspace despite explaining this countless
> times?
> 

It isn't that I don't think they are important.  It is that I think they
are universally provided (when not connectable).
If we add an EXPORT_OP_STABLE_FILEHANDLES flag, I believe we would need to
set it on every export_operations structure.  So what would be the
point?

Thanks,
NeilBrown

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Jeff Layton]

On Wed, 2026-01-21 at 21:34 +1100, NeilBrown wrote:
> On Wed, 21 Jan 2026, Christoph Hellwig wrote:
> 
> > 
> > > 
> > > It took me a while to sift through the code/patches/comments and come to
> > > this understanding and I apologise if I wasn't as clear earlier.  But
> > > my intuition was always that file handle stability was never the real
> > > issue, and maintainer choice was.  Hence my rejection of the
> > > "STABLE_HANDLES" name.
> > 
> > Why do you keep ignoring the fat that the stable handles are really
> > important for anyone wanting to actually use them for their original
> > storage purpose, be that for knfsd, a userland nfs damon, or other
> > storage applications in userspace despite explaining this countless
> > times?
> > 
> 
> It isn't that I don't think they are important.  It is that I think they
> are universally provided (when not connectable).
> If we add an EXPORT_OP_STABLE_FILEHANDLES flag, I believe we would need to
> set it on every export_operations structure.  So what would be the
> point?
> 

I see your point.

Using your definitions, stability is not a problem for Linux
filesystems. The filehandles generally don't change after they have
been established.

Uniqueness however _is_ a problem as we can end up with valid handles
for files that have been recreated across a reboot with some
filesystems (esp. "synthetic" ones like cgroupfs, pidfs, etc.). Naming
the flag STABLE conflates the two.

In an earlier email, HCH said:

> We'll still need a stable handles flag, and expose it to userspace
> to avoid applications being tricked into using broken non-stable
> file handles.  We should have caught that when they were added, but
> didn't unfortunately.
> 

If we assume he meant "unique handles" flag, then I think we're all
mostly in agreement here.  As far as this patchset goes: what if we
were to just rename EXPORT_OP_STABLE_HANDLES to
EXPORT_OP_UNIQUE_HANDLES (and clean up the documentation), since that's
the main issue for existing filesystems. It would be fairly simple to
advertise handle uniqueness using statx or something.

Alternately, instead of denying access to these filesystems, we could
just fix these filesystems to create unique handles (a'la random
i_generation value or something similar). That should mostly prevent
filehandles from being reusable across a reboot on these filesystems.

That would leave cgroupfs and the like exportable via nfsd, but as you
point out, we can't deny export by userland servers. If people want to
do this kind of crazy stuff, maybe we shouldn't deny them after all.

-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christoph Hellwig]

On Wed, Jan 21, 2026 at 09:27:38AM -0500, Jeff Layton wrote:
> Using your definitions, stability is not a problem for Linux
> filesystems. The filehandles generally don't change after they have
> been established.

fat seems to be an exception as far as the 'real' file systems go.
And it did sound to me like some of the synthetic ones had similar
issues.

> > We'll still need a stable handles flag, and expose it to userspace
> > to avoid applications being tricked into using broken non-stable
> > file handles.  We should have caught that when they were added, but
> > didn't unfortunately.
> > 
> 
> If we assume he meant "unique handles" flag, then I think we're all
> mostly in agreement here.  As far as this patchset goes: what if we
> were to just rename EXPORT_OP_STABLE_HANDLES to
> EXPORT_OP_UNIQUE_HANDLES (and clean up the documentation), since that's
> the main issue for existing filesystems. It would be fairly simple to
> advertise handle uniqueness using statx or something.

Unique seems to also only capture part of it, but I could absolutely
live with it, if the documentation includes all aspecs.  But maybe
use persistent as in the nfs spec?

> 
> Alternately, instead of denying access to these filesystems, we could
> just fix these filesystems to create unique handles (a'la random
> i_generation value or something similar). That should mostly prevent
> filehandles from being reusable across a reboot on these filesystems.

Do we even want to provide access to them?

> That would leave cgroupfs and the like exportable via nfsd, but as you
> point out, we can't deny export by userland servers. If people want to
> do this kind of crazy stuff, maybe we shouldn't deny them after all.

I think Amirs patch would take care of that.  Although userland nfs
servers or other storage applications using the handle syscalls would
still see them.  Then again fixing the problem that some handles
did not fulfill the long standing (but not documented well enough)
semantics probably is a good fix on it's own.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Jeff Layton]

On Wed, 2026-01-21 at 06:47 -0800, Christoph Hellwig wrote:
> On Wed, Jan 21, 2026 at 09:27:38AM -0500, Jeff Layton wrote:
> > Using your definitions, stability is not a problem for Linux
> > filesystems. The filehandles generally don't change after they have
> > been established.
> 
> fat seems to be an exception as far as the 'real' file systems go.
> And it did sound to me like some of the synthetic ones had similar
> issues.
> 

Not sure what we can do about FAT without changing the filehandle
format in some fashion. The export ops just use
generic_encode_ino32_fh, and FAT doesn't have stable inode numbers.
The "nostale" ops seem sane enough but it looks like they only work
with the fs in r/o mode.

...and therein lies a problem. We can't reasonably stop exporting FAT
(even with all of its issues), and it in no way meets the definition of
persistent or unique handles.

> > > We'll still need a stable handles flag, and expose it to userspace
> > > to avoid applications being tricked into using broken non-stable
> > > file handles.  We should have caught that when they were added, but
> > > didn't unfortunately.
> > > 
> > 
> > If we assume he meant "unique handles" flag, then I think we're all
> > mostly in agreement here.  As far as this patchset goes: what if we
> > were to just rename EXPORT_OP_STABLE_HANDLES to
> > EXPORT_OP_UNIQUE_HANDLES (and clean up the documentation), since that's
> > the main issue for existing filesystems. It would be fairly simple to
> > advertise handle uniqueness using statx or something.
> 
> Unique seems to also only capture part of it, but I could absolutely
> live with it, if the documentation includes all aspecs.  But maybe
> use persistent as in the nfs spec?

The spec also has the concept of uniqueness. There is an attribute for
that:

    5.8.1.10. Attribute 9: unique_handles

    TRUE, if two distinct filehandles are guaranteed to refer to two different file system objects.

So, the NFSv4 spec does allow for non-unique handles (oh, the
humanity). Persistence has more to do with being non-volatile, AFAICT:

FH4_PERSISTENT
        The value of FH4_PERSISTENT is used to indicate a persistent
filehandle, which is valid until the object is removed from the file
system. The server will not return NFS4ERR_FHEXPIRED for this
filehandle. FH4_PERSISTENT is defined as a value in which none of the
bits specified below are set.

In this case, the filesystems we're most concerned about do not provide
uniqueness, but do provide persistence.

> > 
> > Alternately, instead of denying access to these filesystems, we could
> > just fix these filesystems to create unique handles (a'la random
> > i_generation value or something similar). That should mostly prevent
> > filehandles from being reusable across a reboot on these filesystems.
> 
> Do we even want to provide access to them?
> 

The point would be that there would be no need to flag them, since all
filehandles would then meet the technical definition of unique and
persistent (modulo FAT of course).


> > That would leave cgroupfs and the like exportable via nfsd, but as you
> > point out, we can't deny export by userland servers. If people want to
> > do this kind of crazy stuff, maybe we shouldn't deny them after all.
> 
> I think Amirs patch would take care of that.  Although userland nfs
> servers or other storage applications using the handle syscalls would
> still see them.  Then again fixing the problem that some handles
> did not fulfill the long standing (but not documented well enough)
> semantics probably is a good fix on it's own.

Agreed. We should try to ensure uniqueness and persistence in all
filehandles both for nfsd and userland applications.
-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christoph Hellwig]

On Wed, Jan 21, 2026 at 10:18:00AM -0500, Jeff Layton wrote:
> > fat seems to be an exception as far as the 'real' file systems go.
> > And it did sound to me like some of the synthetic ones had similar
> > issues.
> > 
> 
> Not sure what we can do about FAT without changing the filehandle
> format in some fashion. The export ops just use
> generic_encode_ino32_fh, and FAT doesn't have stable inode numbers.
> The "nostale" ops seem sane enough but it looks like they only work
> with the fs in r/o mode.

Yeah.  I guess we need to ignore this because of <history>

> > I think Amirs patch would take care of that.  Although userland nfs
> > servers or other storage applications using the handle syscalls would
> > still see them.  Then again fixing the problem that some handles
> > did not fulfill the long standing (but not documented well enough)
> > semantics probably is a good fix on it's own.
> 
> Agreed. We should try to ensure uniqueness and persistence in all
> filehandles both for nfsd and userland applications.

Sounds good to me.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Jeff Layton]

On Wed, 2026-01-21 at 22:37 -0800, Christoph Hellwig wrote:
> On Wed, Jan 21, 2026 at 10:18:00AM -0500, Jeff Layton wrote:
> > > fat seems to be an exception as far as the 'real' file systems go.
> > > And it did sound to me like some of the synthetic ones had similar
> > > issues.
> > > 
> > 
> > Not sure what we can do about FAT without changing the filehandle
> > format in some fashion. The export ops just use
> > generic_encode_ino32_fh, and FAT doesn't have stable inode numbers.
> > The "nostale" ops seem sane enough but it looks like they only work
> > with the fs in r/o mode.
> 
> Yeah.  I guess we need to ignore this because of <history>
> 

Yep. This is a case where the handles are not PERSISTENT but I don't
think we can get away with making FAT unexportable. We're probably
stuck with it.

> > > I think Amirs patch would take care of that.  Although userland nfs
> > > servers or other storage applications using the handle syscalls would
> > > still see them.  Then again fixing the problem that some handles
> > > did not fulfill the long standing (but not documented well enough)
> > > semantics probably is a good fix on it's own.
> > 
> > Agreed. We should try to ensure uniqueness and persistence in all
> > filehandles both for nfsd and userland applications.
> 
> Sounds good to me.


Unfortunately, there are already exceptions. Apparently pidfs and
cgroupfs handles (at least) can't be extended because of userspace
expectations:

https://lore.kernel.org/linux-nfs/20260120-irrelevant-zeilen-b3c40a8e6c30@brauner/

My personal take is that we should try to make handle uniqueness a goal
for most existing filesystems, but we're going to have some that can't
achieve that. For them we probably want to be able to flag them so they
can be id'ed by userland.

So, we will need an export_operations flag of some sort
(EXPORT_OP_UNIQUE_HANDLES?). At that point, we'll have to decide
whether to deny nfsd export based on that flag:

We could deny export of any fs that doesn't set the flag, but NFSv4
actually allows the server to advertise that it can't guarantee handle
uniqueness. There isn't much guidance for the client on how to handle
that though and the attribute seems to have the scope of the entire NFS
server.

-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Darrick J. Wong]

On Thu, Jan 22, 2026 at 07:12:36AM -0500, Jeff Layton wrote:
> On Wed, 2026-01-21 at 22:37 -0800, Christoph Hellwig wrote:
> > On Wed, Jan 21, 2026 at 10:18:00AM -0500, Jeff Layton wrote:
> > > > fat seems to be an exception as far as the 'real' file systems go.
> > > > And it did sound to me like some of the synthetic ones had similar
> > > > issues.
> > > > 
> > > 
> > > Not sure what we can do about FAT without changing the filehandle
> > > format in some fashion. The export ops just use
> > > generic_encode_ino32_fh, and FAT doesn't have stable inode numbers.
> > > The "nostale" ops seem sane enough but it looks like they only work
> > > with the fs in r/o mode.
> > 
> > Yeah.  I guess we need to ignore this because of <history>
> > 
> 
> Yep. This is a case where the handles are not PERSISTENT but I don't
> think we can get away with making FAT unexportable. We're probably
> stuck with it.
> 
> > > > I think Amirs patch would take care of that.  Although userland nfs
> > > > servers or other storage applications using the handle syscalls would
> > > > still see them.  Then again fixing the problem that some handles
> > > > did not fulfill the long standing (but not documented well enough)
> > > > semantics probably is a good fix on it's own.
> > > 
> > > Agreed. We should try to ensure uniqueness and persistence in all
> > > filehandles both for nfsd and userland applications.
> > 
> > Sounds good to me.
> 
> 
> Unfortunately, there are already exceptions. Apparently pidfs and
> cgroupfs handles (at least) can't be extended because of userspace
> expectations:
> 
> https://lore.kernel.org/linux-nfs/20260120-irrelevant-zeilen-b3c40a8e6c30@brauner/

systemd cracking file handles??  Yeesh, I thought userspace was supposed
to treat a file handle as an opaque N-byte blob and nothing more, and
only certain "special" tools (e.g. xfsprogs on XFS) could do more than
that.

--D

> My personal take is that we should try to make handle uniqueness a goal
> for most existing filesystems, but we're going to have some that can't
> achieve that. For them we probably want to be able to flag them so they
> can be id'ed by userland.
> 
> So, we will need an export_operations flag of some sort
> (EXPORT_OP_UNIQUE_HANDLES?). At that point, we'll have to decide
> whether to deny nfsd export based on that flag:
> 
> We could deny export of any fs that doesn't set the flag, but NFSv4
> actually allows the server to advertise that it can't guarantee handle
> uniqueness. There isn't much guidance for the client on how to handle
> that though and the attribute seems to have the scope of the entire NFS
> server.
> 
> -- 
> Jeff Layton <jlayton@kernel.org>
> 

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Jeff Layton]

On Tue, 2026-01-20 at 20:27 +1100, NeilBrown wrote:
> On Tue, 20 Jan 2026, Christoph Hellwig wrote:
> > On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> > > This sounds like you are recommending that we give in to bullying.
> > 
> > I find your suggestion that anything you disagree with is bullying
> > extremely offensive.  If you have valid reasons for naming something
> > after the user instead of explaining the semantics, please explain that.
> 
> I was referring not to your behaviour but to this statement by Christian:
> 
>   So if Christoph insists on the other name then I say let's just go with it.
> 
> I think that someone "insisting" on something rather than "arguing
> rationally" for something "sounds like" bullying.  Had Christian said
> something like "Christoph has convinced me of the wisdom of his choice"
> that would have been very different.
> 
> I am quite happy to have reasoned discussions with people who disagree
> with me.  I hope to always provide new relevant information, and hope
> they will too.
> 
> > 
> > If you think NFS actually explains the semantics pretty well, please
> > explain that too, especially in forms that can be put into
> > documentation, including for the user ABI.
> 
> There are multiple issues here:
> 
>  - filehandle stability.  As far as I know all filesystems provide
>    stable filehandles when the "subtree_check" export option is not used.
>    Certainly cgroupfs does.  So having an EXPORT_OP_STABLE_HANDLES
>    flag would mean it was set for every filesystem - unless there is
>    something else I'm not aware of.  That is certainly possible and I
>    hope someone will let me know if I'm missing something.
> 
>  - filehandle uniqueness.  This is somewhat important and if a
>    filesystem doesn't provide it, that should be considered a bug.  In a
>    different thread Christian has observed that there would be benefit
>    if pidfs and nsfs provided uniqueness across reboots.  It is quite
>    easy for a virtual filesystem to generate a 64 bit random number when
>    the fs is initialised, and include that in file handles.  Having a
>    EXPORT_OP_REUSES_HANDLES flag could mark filesystems that are still
>    buggy if that is thought to be useful.
> 

I was conflating "uniqueness" with "stability" wrt cgroupfs. cgroupfs
does have _stable_ handles, by your definition above. What it does not
provide is proper uniqueness since it can end up reusing a filehandle
after a reboot. Maybe that is the better thing to flag here.


>  - GETATTR always reporting file size of 0.  This is the only concrete
>    symptom that Jeff has reported (that I have seen).  This  makes it
>    impossible to read files over NFS even if they have content.
>    Would EXPORT_OP_INACCURATE_SIZE be useful?
> 

Ahh yes, that is probably why I was getting 0 length files when
reading. Likely fixable if anyone cares I suppose.

>  - maintainer feature choice.  A maintainer may choose not to support
>    export over NFS because they feel that there is no value and the
>    possible support burden would not be worth it.  There may be locking
>    / lease / etc issues that further complicate things.  So it might be
>    reasonable for a maintainer to choose to forbid NFS export while
>    allowing local fhandle access. EXPORT_OP_NO_NFS_EXPORT.
> 


> It took me a while to sift through the code/patches/comments and come to
> this understanding and I apologise if I wasn't as clear earlier.  But
> my intuition was always that file handle stability was never the real
> issue, and maintainer choice was.  Hence my rejection of the
> "STABLE_HANDLES" name.
> 

Thanks for laying all that out. You're quite right that this covers
more than handle stability.

At this point, I'm not sure what to do with this set since there are a
lot of competing proposals. In the near term, I'm fine with Amir's
patch.
-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christian Brauner]

On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> On Mon, 19 Jan 2026, Christian Brauner wrote:
> > On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote:
> > > On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> > > > On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > > > > This was Chuck's suggested name. His point was that STABLE means that
> > > > > > the FH's don't change during the lifetime of the file.
> > > > > > 
> > > > > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > > > > better I'll roll with that.
> > > > > 
> > > > > I don't like PERSISTENT.
> > > > > I'd rather call a spade a spade.
> > > > > 
> > > > >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > > > > or
> > > > >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > > > > 
> > > > > The issue here is NFS export and indirection doesn't bring any benefits.
> > > > 
> > > > No, it absolutely is not.  And the whole concept of calling something
> > > > after the initial or main use is a recipe for a mess.
> > > 
> > > We are calling it for it's only use.  If there was ever another use, we
> > > could change the name if that made sense.  It is not a public name, it
> > > is easy to change.
> > > 
> > > > 
> > > > Pick a name that conveys what the flag is about, and document those
> > > > semantics well.  This flag is about the fact that for a given file,
> > > > as long as that file exists in the file system the handle is stable.
> > > > Both stable and persistent are suitable for that, nfs is everything
> > > > but.
> > > 
> > > My understanding is that kernfs would not get the flag.
> > > kernfs filehandles do not change as long as the file exist.
> > > But this is not sufficient for the files to be usefully exported.
> > > 
> > > I suspect kernfs does re-use filehandles relatively soon after the
> > > file/object has been destroyed.  Maybe that is the real problem here:
> > > filehandle reuse, not filehandle stability.
> > > 
> > > Jeff: could you please give details (and preserve them in future cover
> > > letters) of which filesystems are known to have problems and what
> > > exactly those problems are?
> > > 
> > > > 
> > > > Remember nfs also support volatile file handles, and other applications
> > > > might rely on this (I know of quite a few user space applications that
> > > > do, but they are kinda hardwired to xfs anyway).
> > > 
> > > The NFS protocol supports volatile file handles.  knfsd does not.
> > > So maybe
> > >   EXPORT_OP_NOT_NFSD_COMPATIBLE
> > > might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> > > (I prefer opt-out rather than opt-in because nfsd export was the
> > > original purpose of export_operations, but it isn't something
> > > I would fight for)
> > 
> > I prefer one of the variants you proposed here but I don't particularly
> > care. It's not a hill worth dying on. So if Christoph insists on the
> > other name then I say let's just go with it.
> > 
> 
> This sounds like you are recommending that we give in to bullying.
> I would rather the decision be made based on the facts of the case, not
> the opinions that are stated most bluntly.
> 
> I actually think that what Christoph wants is actually quite different
> from what Jeff wants, and maybe two flags are needed.  But I don't yet
> have a clear understanding of what Christoph wants, so I cannot be sure.

I've tried to indirectly ask whether you would be willing to compromise
here or whether you want to insist on your alternative name. Apparently
that didn't come through.

I'm unclear what your goal is in suggesting that I recommend "we" give
into bullying. All it achieved was to further derail this thread.

I also think it's not very helpful at v6 of the discussion to start
figuring out what the actual key rift between Jeff's and Christoph's
position is. If you've figured it out and gotten an agreement and this
is already in, send a follow-up series.

If I don't like it I can always just rename it to EXPORT_OP_DONKEY_KONG
when applying.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[NeilBrown]

On Tue, 20 Jan 2026, Christian Brauner wrote:
> On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> > On Mon, 19 Jan 2026, Christian Brauner wrote:
> > > On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote:
> > > > On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> > > > > On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > > > > > This was Chuck's suggested name. His point was that STABLE means that
> > > > > > > the FH's don't change during the lifetime of the file.
> > > > > > > 
> > > > > > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > > > > > better I'll roll with that.
> > > > > > 
> > > > > > I don't like PERSISTENT.
> > > > > > I'd rather call a spade a spade.
> > > > > > 
> > > > > >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > > > > > or
> > > > > >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > > > > > 
> > > > > > The issue here is NFS export and indirection doesn't bring any benefits.
> > > > > 
> > > > > No, it absolutely is not.  And the whole concept of calling something
> > > > > after the initial or main use is a recipe for a mess.
> > > > 
> > > > We are calling it for it's only use.  If there was ever another use, we
> > > > could change the name if that made sense.  It is not a public name, it
> > > > is easy to change.
> > > > 
> > > > > 
> > > > > Pick a name that conveys what the flag is about, and document those
> > > > > semantics well.  This flag is about the fact that for a given file,
> > > > > as long as that file exists in the file system the handle is stable.
> > > > > Both stable and persistent are suitable for that, nfs is everything
> > > > > but.
> > > > 
> > > > My understanding is that kernfs would not get the flag.
> > > > kernfs filehandles do not change as long as the file exist.
> > > > But this is not sufficient for the files to be usefully exported.
> > > > 
> > > > I suspect kernfs does re-use filehandles relatively soon after the
> > > > file/object has been destroyed.  Maybe that is the real problem here:
> > > > filehandle reuse, not filehandle stability.
> > > > 
> > > > Jeff: could you please give details (and preserve them in future cover
> > > > letters) of which filesystems are known to have problems and what
> > > > exactly those problems are?
> > > > 
> > > > > 
> > > > > Remember nfs also support volatile file handles, and other applications
> > > > > might rely on this (I know of quite a few user space applications that
> > > > > do, but they are kinda hardwired to xfs anyway).
> > > > 
> > > > The NFS protocol supports volatile file handles.  knfsd does not.
> > > > So maybe
> > > >   EXPORT_OP_NOT_NFSD_COMPATIBLE
> > > > might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> > > > (I prefer opt-out rather than opt-in because nfsd export was the
> > > > original purpose of export_operations, but it isn't something
> > > > I would fight for)
> > > 
> > > I prefer one of the variants you proposed here but I don't particularly
> > > care. It's not a hill worth dying on. So if Christoph insists on the
> > > other name then I say let's just go with it.
> > > 
> > 
> > This sounds like you are recommending that we give in to bullying.
> > I would rather the decision be made based on the facts of the case, not
> > the opinions that are stated most bluntly.
> > 
> > I actually think that what Christoph wants is actually quite different
> > from what Jeff wants, and maybe two flags are needed.  But I don't yet
> > have a clear understanding of what Christoph wants, so I cannot be sure.
> 
> I've tried to indirectly ask whether you would be willing to compromise
> here or whether you want to insist on your alternative name. Apparently
> that didn't come through.

This would be the "not a hill worthy dying on" part of your statement.
I think I see that implication now.
But no, I don't think compromise is relevant.  I think the problem
statement as originally given by Jeff is misleading, and people have
been misled to an incorrect name.

> 
> I'm unclear what your goal is in suggesting that I recommend "we" give
> into bullying. All it achieved was to further derail this thread.
> 

The "We" is the same as the "us" in "let's just go with it".


> I also think it's not very helpful at v6 of the discussion to start
> figuring out what the actual key rift between Jeff's and Christoph's
> position is. If you've figured it out and gotten an agreement and this
> is already in, send a follow-up series.

v6?  v2 was posted today.  But maybe you are referring the some other
precursors.

The introductory statement in v2 is

   This patchset adds a flag that indicates whether the filesystem supports
   stable filehandles (i.e. that they don't change over the life of the
   file). It then makes any filesystem that doesn't set that flag
   ineligible for nfsd export.

Nobody else questioned the validity of that.  I do.
No evidence was given that there are *any* filesystems that don't
support stable filehandles.  The only filesystem mentioned is cgroups
and it DOES provide stable filehandles.

NeilBrown

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christian Brauner]

On Tue, Jan 20, 2026 at 08:41:50PM +1100, NeilBrown wrote:
> On Tue, 20 Jan 2026, Christian Brauner wrote:
> > On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> > > On Mon, 19 Jan 2026, Christian Brauner wrote:
> > > > On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote:
> > > > > On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> > > > > > On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > > > > > > This was Chuck's suggested name. His point was that STABLE means that
> > > > > > > > the FH's don't change during the lifetime of the file.
> > > > > > > > 
> > > > > > > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > > > > > > better I'll roll with that.
> > > > > > > 
> > > > > > > I don't like PERSISTENT.
> > > > > > > I'd rather call a spade a spade.
> > > > > > > 
> > > > > > >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > > > > > > or
> > > > > > >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > > > > > > 
> > > > > > > The issue here is NFS export and indirection doesn't bring any benefits.
> > > > > > 
> > > > > > No, it absolutely is not.  And the whole concept of calling something
> > > > > > after the initial or main use is a recipe for a mess.
> > > > > 
> > > > > We are calling it for it's only use.  If there was ever another use, we
> > > > > could change the name if that made sense.  It is not a public name, it
> > > > > is easy to change.
> > > > > 
> > > > > > 
> > > > > > Pick a name that conveys what the flag is about, and document those
> > > > > > semantics well.  This flag is about the fact that for a given file,
> > > > > > as long as that file exists in the file system the handle is stable.
> > > > > > Both stable and persistent are suitable for that, nfs is everything
> > > > > > but.
> > > > > 
> > > > > My understanding is that kernfs would not get the flag.
> > > > > kernfs filehandles do not change as long as the file exist.
> > > > > But this is not sufficient for the files to be usefully exported.
> > > > > 
> > > > > I suspect kernfs does re-use filehandles relatively soon after the
> > > > > file/object has been destroyed.  Maybe that is the real problem here:
> > > > > filehandle reuse, not filehandle stability.
> > > > > 
> > > > > Jeff: could you please give details (and preserve them in future cover
> > > > > letters) of which filesystems are known to have problems and what
> > > > > exactly those problems are?
> > > > > 
> > > > > > 
> > > > > > Remember nfs also support volatile file handles, and other applications
> > > > > > might rely on this (I know of quite a few user space applications that
> > > > > > do, but they are kinda hardwired to xfs anyway).
> > > > > 
> > > > > The NFS protocol supports volatile file handles.  knfsd does not.
> > > > > So maybe
> > > > >   EXPORT_OP_NOT_NFSD_COMPATIBLE
> > > > > might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> > > > > (I prefer opt-out rather than opt-in because nfsd export was the
> > > > > original purpose of export_operations, but it isn't something
> > > > > I would fight for)
> > > > 
> > > > I prefer one of the variants you proposed here but I don't particularly
> > > > care. It's not a hill worth dying on. So if Christoph insists on the
> > > > other name then I say let's just go with it.
> > > > 
> > > 
> > > This sounds like you are recommending that we give in to bullying.
> > > I would rather the decision be made based on the facts of the case, not
> > > the opinions that are stated most bluntly.
> > > 
> > > I actually think that what Christoph wants is actually quite different
> > > from what Jeff wants, and maybe two flags are needed.  But I don't yet
> > > have a clear understanding of what Christoph wants, so I cannot be sure.
> > 
> > I've tried to indirectly ask whether you would be willing to compromise
> > here or whether you want to insist on your alternative name. Apparently
> > that didn't come through.
> 
> This would be the "not a hill worthy dying on" part of your statement.
> I think I see that implication now.
> But no, I don't think compromise is relevant.  I think the problem
> statement as originally given by Jeff is misleading, and people have
> been misled to an incorrect name.
> 
> > 
> > I'm unclear what your goal is in suggesting that I recommend "we" give
> > into bullying. All it achieved was to further derail this thread.
> > 
> 
> The "We" is the same as the "us" in "let's just go with it".
> 
> 
> > I also think it's not very helpful at v6 of the discussion to start
> > figuring out what the actual key rift between Jeff's and Christoph's
> > position is. If you've figured it out and gotten an agreement and this
> > is already in, send a follow-up series.
> 
> v6?  v2 was posted today.  But maybe you are referring the some other
> precursors.
> 
> The introductory statement in v2 is
> 
>    This patchset adds a flag that indicates whether the filesystem supports
>    stable filehandles (i.e. that they don't change over the life of the
>    file). It then makes any filesystem that doesn't set that flag
>    ineligible for nfsd export.
> 
> Nobody else questioned the validity of that.  I do.
> No evidence was given that there are *any* filesystems that don't
> support stable filehandles.  The only filesystem mentioned is cgroups
> and it DOES provide stable filehandles.

Oh yes we did. And this is a merry-go-round.

It is very much fine for a filesystems to support file handles without
wanting to support exporting via NFS. That is especially true for
in-kernel pseudo filesystems.

As I've said before multiple times I want a way to allow filesystems
such as pidfs and nsfs to use file handles without supporting export.
Whatever that fscking flag is called at this point I fundamentally don't
care. And we are reliving the same arguments over and over.

I will _hard NAK_ anything that starts mandating that export of
filesystems must be allowed simply because their file handles fit export
criteria. I do not care whether pidfs or nsfs file handles fit the bill.
They will not be exported.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Jeff Layton]

On Tue, 2026-01-20 at 11:31 +0100, Christian Brauner wrote:
> On Tue, Jan 20, 2026 at 08:41:50PM +1100, NeilBrown wrote:
> > On Tue, 20 Jan 2026, Christian Brauner wrote:
> > > On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> > > > On Mon, 19 Jan 2026, Christian Brauner wrote:
> > > > > On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote:
> > > > > > On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> > > > > > > On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > > > > > > > This was Chuck's suggested name. His point was that STABLE means that
> > > > > > > > > the FH's don't change during the lifetime of the file.
> > > > > > > > > 
> > > > > > > > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > > > > > > > better I'll roll with that.
> > > > > > > > 
> > > > > > > > I don't like PERSISTENT.
> > > > > > > > I'd rather call a spade a spade.
> > > > > > > > 
> > > > > > > >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > > > > > > > or
> > > > > > > >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > > > > > > > 
> > > > > > > > The issue here is NFS export and indirection doesn't bring any benefits.
> > > > > > > 
> > > > > > > No, it absolutely is not.  And the whole concept of calling something
> > > > > > > after the initial or main use is a recipe for a mess.
> > > > > > 
> > > > > > We are calling it for it's only use.  If there was ever another use, we
> > > > > > could change the name if that made sense.  It is not a public name, it
> > > > > > is easy to change.
> > > > > > 
> > > > > > > 
> > > > > > > Pick a name that conveys what the flag is about, and document those
> > > > > > > semantics well.  This flag is about the fact that for a given file,
> > > > > > > as long as that file exists in the file system the handle is stable.
> > > > > > > Both stable and persistent are suitable for that, nfs is everything
> > > > > > > but.
> > > > > > 
> > > > > > My understanding is that kernfs would not get the flag.
> > > > > > kernfs filehandles do not change as long as the file exist.
> > > > > > But this is not sufficient for the files to be usefully exported.
> > > > > > 
> > > > > > I suspect kernfs does re-use filehandles relatively soon after the
> > > > > > file/object has been destroyed.  Maybe that is the real problem here:
> > > > > > filehandle reuse, not filehandle stability.
> > > > > > 
> > > > > > Jeff: could you please give details (and preserve them in future cover
> > > > > > letters) of which filesystems are known to have problems and what
> > > > > > exactly those problems are?
> > > > > > 
> > > > > > > 
> > > > > > > Remember nfs also support volatile file handles, and other applications
> > > > > > > might rely on this (I know of quite a few user space applications that
> > > > > > > do, but they are kinda hardwired to xfs anyway).
> > > > > > 
> > > > > > The NFS protocol supports volatile file handles.  knfsd does not.
> > > > > > So maybe
> > > > > >   EXPORT_OP_NOT_NFSD_COMPATIBLE
> > > > > > might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> > > > > > (I prefer opt-out rather than opt-in because nfsd export was the
> > > > > > original purpose of export_operations, but it isn't something
> > > > > > I would fight for)
> > > > > 
> > > > > I prefer one of the variants you proposed here but I don't particularly
> > > > > care. It's not a hill worth dying on. So if Christoph insists on the
> > > > > other name then I say let's just go with it.
> > > > > 
> > > > 
> > > > This sounds like you are recommending that we give in to bullying.
> > > > I would rather the decision be made based on the facts of the case, not
> > > > the opinions that are stated most bluntly.
> > > > 
> > > > I actually think that what Christoph wants is actually quite different
> > > > from what Jeff wants, and maybe two flags are needed.  But I don't yet
> > > > have a clear understanding of what Christoph wants, so I cannot be sure.
> > > 
> > > I've tried to indirectly ask whether you would be willing to compromise
> > > here or whether you want to insist on your alternative name. Apparently
> > > that didn't come through.
> > 
> > This would be the "not a hill worthy dying on" part of your statement.
> > I think I see that implication now.
> > But no, I don't think compromise is relevant.  I think the problem
> > statement as originally given by Jeff is misleading, and people have
> > been misled to an incorrect name.
> > 
> > > 
> > > I'm unclear what your goal is in suggesting that I recommend "we" give
> > > into bullying. All it achieved was to further derail this thread.
> > > 
> > 
> > The "We" is the same as the "us" in "let's just go with it".
> > 
> > 
> > > I also think it's not very helpful at v6 of the discussion to start
> > > figuring out what the actual key rift between Jeff's and Christoph's
> > > position is. If you've figured it out and gotten an agreement and this
> > > is already in, send a follow-up series.
> > 
> > v6?  v2 was posted today.  But maybe you are referring the some other
> > precursors.
> > 
> > The introductory statement in v2 is
> > 
> >    This patchset adds a flag that indicates whether the filesystem supports
> >    stable filehandles (i.e. that they don't change over the life of the
> >    file). It then makes any filesystem that doesn't set that flag
> >    ineligible for nfsd export.
> > 
> > Nobody else questioned the validity of that.  I do.
> > No evidence was given that there are *any* filesystems that don't
> > support stable filehandles.  The only filesystem mentioned is cgroups
> > and it DOES provide stable filehandles.
> 

Across reboot? Not really.

It's quite possible that we may end up with the same "id" numbers in
cgroupfs on a new incarnation of the filesystem after a reboot. The
files in there are not the same ones as the ones before, but their
filehandles may match because kernfs doesn't factor in an i_generation
number.

Could we fix it by adding a random i_generation value or something?
Possibly, but there really isn't a good use-case that I can see for
allowing cgroupfs to be exported via nfsd. Best to disallow it until
someone comes up with one.

> Oh yes we did. And this is a merry-go-round.
> 
> It is very much fine for a filesystems to support file handles without
> wanting to support exporting via NFS. That is especially true for
> in-kernel pseudo filesystems.
> 
> As I've said before multiple times I want a way to allow filesystems
> such as pidfs and nsfs to use file handles without supporting export.
> Whatever that fscking flag is called at this point I fundamentally don't
> care. And we are reliving the same arguments over and over.
> 
> I will _hard NAK_ anything that starts mandating that export of
> filesystems must be allowed simply because their file handles fit export
> criteria. I do not care whether pidfs or nsfs file handles fit the bill.
> They will not be exported.

I don't really care what we call the flag. I do care a little about
what its semantics are, but the effect should be to ensure that fs
maintainers make a conscious decision about whether nfsd export should
be allowed on the filesystem. 

At this point, maybe we should just go with Neil's 
EXPORT_OP_SUPPORTS_NFS_EXPORT or something. It's much more arbitrary,
than trying to base this on criteria about filehandle stability, but it
would give us the effect we want.

-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[NeilBrown]

On Tue, 20 Jan 2026, Jeff Layton wrote:
> On Tue, 2026-01-20 at 11:31 +0100, Christian Brauner wrote:
> > On Tue, Jan 20, 2026 at 08:41:50PM +1100, NeilBrown wrote:
> > > On Tue, 20 Jan 2026, Christian Brauner wrote:
> > > > On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> > > > > On Mon, 19 Jan 2026, Christian Brauner wrote:
> > > > > > On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote:
> > > > > > > On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> > > > > > > > On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > > > > > > > > This was Chuck's suggested name. His point was that STABLE means that
> > > > > > > > > > the FH's don't change during the lifetime of the file.
> > > > > > > > > > 
> > > > > > > > > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > > > > > > > > better I'll roll with that.
> > > > > > > > > 
> > > > > > > > > I don't like PERSISTENT.
> > > > > > > > > I'd rather call a spade a spade.
> > > > > > > > > 
> > > > > > > > >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > > > > > > > > or
> > > > > > > > >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > > > > > > > > 
> > > > > > > > > The issue here is NFS export and indirection doesn't bring any benefits.
> > > > > > > > 
> > > > > > > > No, it absolutely is not.  And the whole concept of calling something
> > > > > > > > after the initial or main use is a recipe for a mess.
> > > > > > > 
> > > > > > > We are calling it for it's only use.  If there was ever another use, we
> > > > > > > could change the name if that made sense.  It is not a public name, it
> > > > > > > is easy to change.
> > > > > > > 
> > > > > > > > 
> > > > > > > > Pick a name that conveys what the flag is about, and document those
> > > > > > > > semantics well.  This flag is about the fact that for a given file,
> > > > > > > > as long as that file exists in the file system the handle is stable.
> > > > > > > > Both stable and persistent are suitable for that, nfs is everything
> > > > > > > > but.
> > > > > > > 
> > > > > > > My understanding is that kernfs would not get the flag.
> > > > > > > kernfs filehandles do not change as long as the file exist.
> > > > > > > But this is not sufficient for the files to be usefully exported.
> > > > > > > 
> > > > > > > I suspect kernfs does re-use filehandles relatively soon after the
> > > > > > > file/object has been destroyed.  Maybe that is the real problem here:
> > > > > > > filehandle reuse, not filehandle stability.
> > > > > > > 
> > > > > > > Jeff: could you please give details (and preserve them in future cover
> > > > > > > letters) of which filesystems are known to have problems and what
> > > > > > > exactly those problems are?
> > > > > > > 
> > > > > > > > 
> > > > > > > > Remember nfs also support volatile file handles, and other applications
> > > > > > > > might rely on this (I know of quite a few user space applications that
> > > > > > > > do, but they are kinda hardwired to xfs anyway).
> > > > > > > 
> > > > > > > The NFS protocol supports volatile file handles.  knfsd does not.
> > > > > > > So maybe
> > > > > > >   EXPORT_OP_NOT_NFSD_COMPATIBLE
> > > > > > > might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> > > > > > > (I prefer opt-out rather than opt-in because nfsd export was the
> > > > > > > original purpose of export_operations, but it isn't something
> > > > > > > I would fight for)
> > > > > > 
> > > > > > I prefer one of the variants you proposed here but I don't particularly
> > > > > > care. It's not a hill worth dying on. So if Christoph insists on the
> > > > > > other name then I say let's just go with it.
> > > > > > 
> > > > > 
> > > > > This sounds like you are recommending that we give in to bullying.
> > > > > I would rather the decision be made based on the facts of the case, not
> > > > > the opinions that are stated most bluntly.
> > > > > 
> > > > > I actually think that what Christoph wants is actually quite different
> > > > > from what Jeff wants, and maybe two flags are needed.  But I don't yet
> > > > > have a clear understanding of what Christoph wants, so I cannot be sure.
> > > > 
> > > > I've tried to indirectly ask whether you would be willing to compromise
> > > > here or whether you want to insist on your alternative name. Apparently
> > > > that didn't come through.
> > > 
> > > This would be the "not a hill worthy dying on" part of your statement.
> > > I think I see that implication now.
> > > But no, I don't think compromise is relevant.  I think the problem
> > > statement as originally given by Jeff is misleading, and people have
> > > been misled to an incorrect name.
> > > 
> > > > 
> > > > I'm unclear what your goal is in suggesting that I recommend "we" give
> > > > into bullying. All it achieved was to further derail this thread.
> > > > 
> > > 
> > > The "We" is the same as the "us" in "let's just go with it".
> > > 
> > > 
> > > > I also think it's not very helpful at v6 of the discussion to start
> > > > figuring out what the actual key rift between Jeff's and Christoph's
> > > > position is. If you've figured it out and gotten an agreement and this
> > > > is already in, send a follow-up series.
> > > 
> > > v6?  v2 was posted today.  But maybe you are referring the some other
> > > precursors.
> > > 
> > > The introductory statement in v2 is
> > > 
> > >    This patchset adds a flag that indicates whether the filesystem supports
> > >    stable filehandles (i.e. that they don't change over the life of the
> > >    file). It then makes any filesystem that doesn't set that flag
> > >    ineligible for nfsd export.
> > > 
> > > Nobody else questioned the validity of that.  I do.
> > > No evidence was given that there are *any* filesystems that don't
> > > support stable filehandles.  The only filesystem mentioned is cgroups
> > > and it DOES provide stable filehandles.
> > 
> 
> Across reboot? Not really.

Across reboot all the files are deleted and then new ones are created.
So there is nothing that needs to be stable.

> 
> It's quite possible that we may end up with the same "id" numbers in
> cgroupfs on a new incarnation of the filesystem after a reboot. The
> files in there are not the same ones as the ones before, but their
> filehandles may match because kernfs doesn't factor in an i_generation
> number.

That is is about filehandle re-use, not about filehandle stability.

> 
> Could we fix it by adding a random i_generation value or something?
> Possibly, but there really isn't a good use-case that I can see for
> allowing cgroupfs to be exported via nfsd. Best to disallow it until
> someone comes up with one.

100% agree.

> 
> > Oh yes we did. And this is a merry-go-round.
> > 
> > It is very much fine for a filesystems to support file handles without
> > wanting to support exporting via NFS. That is especially true for
> > in-kernel pseudo filesystems.
> > 
> > As I've said before multiple times I want a way to allow filesystems
> > such as pidfs and nsfs to use file handles without supporting export.
> > Whatever that fscking flag is called at this point I fundamentally don't
> > care. And we are reliving the same arguments over and over.
> > 
> > I will _hard NAK_ anything that starts mandating that export of
> > filesystems must be allowed simply because their file handles fit export
> > criteria. I do not care whether pidfs or nsfs file handles fit the bill.
> > They will not be exported.
> 
> I don't really care what we call the flag. I do care a little about
> what its semantics are, but the effect should be to ensure that fs
> maintainers make a conscious decision about whether nfsd export should
> be allowed on the filesystem. 

Why do you need a conscious decision so much that you want to try to
force it.
Of course we want conscious decisions and hope they are always made, but
trying to manipulate people to doing things often fails.  How sure are
you that fs developers won't just copy-paste some other implementation
and not think about the implications of the flag?

What is the down side?  What is the harm from allowing export (should the
admin attempt it)?
If there were serious security concerns - then sure, make it harder to
do the dangerous thing.
But if it is just "it doesn't make sense", then there is no harm in
letting people get away with not reading the documentation, and fixing
things later as complaints arrive.  That is generally how the process
works.

But if you really really want to set this new flag on almost every
export_operations, can I ask that you please set it on EVERY export
operations, then allow maintainers to remove it as they see fit.
I think that approach would be much easier to review.

With your current series it is non-trivial to determine which
export_operations you have chosen not to set the flag on.  If you had
one patch that set it everywhere, then individual patches to remove it,
that would be a lot easier to review.

Thanks,
NeilBrown


> 
> At this point, maybe we should just go with Neil's 
> EXPORT_OP_SUPPORTS_NFS_EXPORT or something. It's much more arbitrary,
> than trying to base this on criteria about filehandle stability, but it
> would give us the effect we want.
> 
> -- 
> Jeff Layton <jlayton@kernel.org>
> 

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Jeff Layton]

On Wed, 2026-01-21 at 14:58 +1100, NeilBrown wrote:
> On Tue, 20 Jan 2026, Jeff Layton wrote:
> > On Tue, 2026-01-20 at 11:31 +0100, Christian Brauner wrote:
> > > On Tue, Jan 20, 2026 at 08:41:50PM +1100, NeilBrown wrote:
> > > > On Tue, 20 Jan 2026, Christian Brauner wrote:
> > > > > On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> > > > > > On Mon, 19 Jan 2026, Christian Brauner wrote:
> > > > > > > On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote:
> > > > > > > > On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> > > > > > > > > On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > > > > > > > > > This was Chuck's suggested name. His point was that STABLE means that
> > > > > > > > > > > the FH's don't change during the lifetime of the file.
> > > > > > > > > > > 
> > > > > > > > > > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > > > > > > > > > better I'll roll with that.
> > > > > > > > > > 
> > > > > > > > > > I don't like PERSISTENT.
> > > > > > > > > > I'd rather call a spade a spade.
> > > > > > > > > > 
> > > > > > > > > >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > > > > > > > > > or
> > > > > > > > > >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > > > > > > > > > 
> > > > > > > > > > The issue here is NFS export and indirection doesn't bring any benefits.
> > > > > > > > > 
> > > > > > > > > No, it absolutely is not.  And the whole concept of calling something
> > > > > > > > > after the initial or main use is a recipe for a mess.
> > > > > > > > 
> > > > > > > > We are calling it for it's only use.  If there was ever another use, we
> > > > > > > > could change the name if that made sense.  It is not a public name, it
> > > > > > > > is easy to change.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Pick a name that conveys what the flag is about, and document those
> > > > > > > > > semantics well.  This flag is about the fact that for a given file,
> > > > > > > > > as long as that file exists in the file system the handle is stable.
> > > > > > > > > Both stable and persistent are suitable for that, nfs is everything
> > > > > > > > > but.
> > > > > > > > 
> > > > > > > > My understanding is that kernfs would not get the flag.
> > > > > > > > kernfs filehandles do not change as long as the file exist.
> > > > > > > > But this is not sufficient for the files to be usefully exported.
> > > > > > > > 
> > > > > > > > I suspect kernfs does re-use filehandles relatively soon after the
> > > > > > > > file/object has been destroyed.  Maybe that is the real problem here:
> > > > > > > > filehandle reuse, not filehandle stability.
> > > > > > > > 
> > > > > > > > Jeff: could you please give details (and preserve them in future cover
> > > > > > > > letters) of which filesystems are known to have problems and what
> > > > > > > > exactly those problems are?
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Remember nfs also support volatile file handles, and other applications
> > > > > > > > > might rely on this (I know of quite a few user space applications that
> > > > > > > > > do, but they are kinda hardwired to xfs anyway).
> > > > > > > > 
> > > > > > > > The NFS protocol supports volatile file handles.  knfsd does not.
> > > > > > > > So maybe
> > > > > > > >   EXPORT_OP_NOT_NFSD_COMPATIBLE
> > > > > > > > might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> > > > > > > > (I prefer opt-out rather than opt-in because nfsd export was the
> > > > > > > > original purpose of export_operations, but it isn't something
> > > > > > > > I would fight for)
> > > > > > > 
> > > > > > > I prefer one of the variants you proposed here but I don't particularly
> > > > > > > care. It's not a hill worth dying on. So if Christoph insists on the
> > > > > > > other name then I say let's just go with it.
> > > > > > > 
> > > > > > 
> > > > > > This sounds like you are recommending that we give in to bullying.
> > > > > > I would rather the decision be made based on the facts of the case, not
> > > > > > the opinions that are stated most bluntly.
> > > > > > 
> > > > > > I actually think that what Christoph wants is actually quite different
> > > > > > from what Jeff wants, and maybe two flags are needed.  But I don't yet
> > > > > > have a clear understanding of what Christoph wants, so I cannot be sure.
> > > > > 
> > > > > I've tried to indirectly ask whether you would be willing to compromise
> > > > > here or whether you want to insist on your alternative name. Apparently
> > > > > that didn't come through.
> > > > 
> > > > This would be the "not a hill worthy dying on" part of your statement.
> > > > I think I see that implication now.
> > > > But no, I don't think compromise is relevant.  I think the problem
> > > > statement as originally given by Jeff is misleading, and people have
> > > > been misled to an incorrect name.
> > > > 
> > > > > 
> > > > > I'm unclear what your goal is in suggesting that I recommend "we" give
> > > > > into bullying. All it achieved was to further derail this thread.
> > > > > 
> > > > 
> > > > The "We" is the same as the "us" in "let's just go with it".
> > > > 
> > > > 
> > > > > I also think it's not very helpful at v6 of the discussion to start
> > > > > figuring out what the actual key rift between Jeff's and Christoph's
> > > > > position is. If you've figured it out and gotten an agreement and this
> > > > > is already in, send a follow-up series.
> > > > 
> > > > v6?  v2 was posted today.  But maybe you are referring the some other
> > > > precursors.
> > > > 
> > > > The introductory statement in v2 is
> > > > 
> > > >    This patchset adds a flag that indicates whether the filesystem supports
> > > >    stable filehandles (i.e. that they don't change over the life of the
> > > >    file). It then makes any filesystem that doesn't set that flag
> > > >    ineligible for nfsd export.
> > > > 
> > > > Nobody else questioned the validity of that.  I do.
> > > > No evidence was given that there are *any* filesystems that don't
> > > > support stable filehandles.  The only filesystem mentioned is cgroups
> > > > and it DOES provide stable filehandles.
> > > 
> > 
> > Across reboot? Not really.
> 
> Across reboot all the files are deleted and then new ones are created.
> So there is nothing that needs to be stable.
> 
> > 
> > It's quite possible that we may end up with the same "id" numbers in
> > cgroupfs on a new incarnation of the filesystem after a reboot. The
> > files in there are not the same ones as the ones before, but their
> > filehandles may match because kernfs doesn't factor in an i_generation
> > number.
> 
> That is is about filehandle re-use, not about filehandle stability.
> 
> > 
> > Could we fix it by adding a random i_generation value or something?
> > Possibly, but there really isn't a good use-case that I can see for
> > allowing cgroupfs to be exported via nfsd. Best to disallow it until
> > someone comes up with one.
> 
> 100% agree.
> 
> > 
> > > Oh yes we did. And this is a merry-go-round.
> > > 
> > > It is very much fine for a filesystems to support file handles without
> > > wanting to support exporting via NFS. That is especially true for
> > > in-kernel pseudo filesystems.
> > > 
> > > As I've said before multiple times I want a way to allow filesystems
> > > such as pidfs and nsfs to use file handles without supporting export.
> > > Whatever that fscking flag is called at this point I fundamentally don't
> > > care. And we are reliving the same arguments over and over.
> > > 
> > > I will _hard NAK_ anything that starts mandating that export of
> > > filesystems must be allowed simply because their file handles fit export
> > > criteria. I do not care whether pidfs or nsfs file handles fit the bill.
> > > They will not be exported.
> > 
> > I don't really care what we call the flag. I do care a little about
> > what its semantics are, but the effect should be to ensure that fs
> > maintainers make a conscious decision about whether nfsd export should
> > be allowed on the filesystem. 
> 
> Why do you need a conscious decision so much that you want to try to
> force it.

As I said before, filesystems are growing export_operations for other
reasons than nfs export. I simply want to the fs maintainers to take a
conscious step to say "yes, this should be available via nfsd if it's
exported". Hopefully they'll also validate that it actually _works_
too.

> Of course we want conscious decisions and hope they are always made, but
> trying to manipulate people to doing things often fails.  How sure are
> you that fs developers won't just copy-paste some other implementation
> and not think about the implications of the flag?
>
> What is the down side?  What is the harm from allowing export (should the
> admin attempt it)?
> If there were serious security concerns - then sure, make it harder to
> do the dangerous thing.
> But if it is just "it doesn't make sense", then there is no harm in
> letting people get away with not reading the documentation, and fixing
> things later as complaints arrive.  That is generally how the process
> works.
> 

Some of the more exotic filesystems could end up causing kernel panics
or something if exported when they haven't been validated to actually
work with nfsd. That's mostly FUD though -- I don't have any examples.

> But if you really really want to set this new flag on almost every
> export_operations, can I ask that you please set it on EVERY export
> operations, then allow maintainers to remove it as they see fit.
> I think that approach would be much easier to review.
> 

We could probably do that, but I think the main ones that excludes it
are kernfs, pidfs and nsfs. ovl and fuse also have export ops in
certain modes that exclude NFS access, so the flag was left off of
those as well.

> With your current series it is non-trivial to determine which
> export_operations you have chosen not to set the flag on.  If you had
> one patch that set it everywhere, then individual patches to remove it,
> that would be a lot easier to review.

Noted. At this point I'm debating whether to pursue this further, or
just drop this for now until we can come to a better consensus. Maybe
we need a discussion about this at LSF?

-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Amir Goldstein]

On Wed, Jan 21, 2026 at 12:56 PM Jeff Layton <jlayton@kernel.org> wrote:
>
...
> > But if you really really want to set this new flag on almost every
> > export_operations, can I ask that you please set it on EVERY export
> > operations, then allow maintainers to remove it as they see fit.
> > I think that approach would be much easier to review.
> >
>
> We could probably do that, but I think the main ones that excludes it
> are kernfs, pidfs and nsfs. ovl and fuse also have export ops in
> certain modes that exclude NFS access, so the flag was left off of
> those as well.
>

For the record, my comments regarding fuse_export_fid_operations
and ovl_export_fid_operations variants were purely semantic -
it did not make sense to mark them as _STABLE_HANDLE, but
it does not matter if you set a flag on those ops, because they do
not implement ->fh_to_dentry(), on purpose, they are not
exportfs_can_decode_fh() by design.

Thanks,
Amir.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christoph Hellwig]

On Tue, Jan 20, 2026 at 07:50:32AM -0500, Jeff Layton wrote:
> > > and it DOES provide stable filehandles.
> > 
> 
> Across reboot? Not really.
> 
> It's quite possible that we may end up with the same "id" numbers in
> cgroupfs on a new incarnation of the filesystem after a reboot. The
> files in there are not the same ones as the ones before, but their
> filehandles may match because kernfs doesn't factor in an i_generation
> number.
> 
> Could we fix it by adding a random i_generation value or something?
> Possibly, but there really isn't a good use-case that I can see for
> allowing cgroupfs to be exported via nfsd. Best to disallow it until
> someone comes up with one.

Yeah.  And I'm pretty sure everyone here will push back hard on any
such use case.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christoph Hellwig]

On Tue, Jan 20, 2026 at 07:50:32AM -0500, Jeff Layton wrote:
> At this point, maybe we should just go with Neil's 
> EXPORT_OP_SUPPORTS_NFS_EXPORT or something. It's much more arbitrary,
> than trying to base this on criteria about filehandle stability, but it
> would give us the effect we want.

We'll still need a stable handles flag, and expose it to userspace
to avoid applications being tricked into using broken non-stable
file handles.  We should have caught that when they were added, but
didn't unfortunately.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christoph Hellwig]

On Tue, Jan 20, 2026 at 11:31:54AM +0100, Christian Brauner wrote:
> It is very much fine for a filesystems to support file handles without
> wanting to support exporting via NFS. That is especially true for
> in-kernel pseudo filesystems.

I'm still amazed at this statement.  "Wanting to export" is not
something for the file system to decide on in any kind of sane
layering.  The file systems exports features, and layers higher
in the stack make use of it.  We just need to be precise in describing

In-kernel code will then we so nice to respect it.  But for userspace
even then all bets are off.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christoph Hellwig]

On Tue, Jan 20, 2026 at 10:04:02AM +0100, Christian Brauner wrote:
> > I actually think that what Christoph wants is actually quite different
> > from what Jeff wants, and maybe two flags are needed.  But I don't yet
> > have a clear understanding of what Christoph wants, so I cannot be sure.
> 
> I've tried to indirectly ask whether you would be willing to compromise
> here or whether you want to insist on your alternative name. Apparently
> that didn't come through.

Btw, I don't think the name is the primary problem, as we seem to
disagree even about the problem space.  The current patch series
from Jeff helps with the stable handle problem, which is an important
one, although maybe not the one you and Amir care about most.  I care
about it most, because the addition of unstable handles caused problems
and I really want that fixed before it spreads further, and I think
anything mentioning NFS in that is factually wrong.  If we need
additional flags to work around other issues (as in the list compiled
by Neil) I'd still prefer them to be named about what issues they
deal with, but folks get too tired of that I could probably with a
"NFSD get the f^&&& out" name if we'd just keep shouting at each
other otherwise.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Jeff Layton]

On Mon, 2026-01-19 at 18:22 +1100, NeilBrown wrote:
> On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> > On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > > This was Chuck's suggested name. His point was that STABLE means that
> > > > the FH's don't change during the lifetime of the file.
> > > > 
> > > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > > better I'll roll with that.
> > > 
> > > I don't like PERSISTENT.
> > > I'd rather call a spade a spade.
> > > 
> > >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > > or
> > >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > > 
> > > The issue here is NFS export and indirection doesn't bring any benefits.
> > 
> > No, it absolutely is not.  And the whole concept of calling something
> > after the initial or main use is a recipe for a mess.
> 
> We are calling it for it's only use.  If there was ever another use, we
> could change the name if that made sense.  It is not a public name, it
> is easy to change.
> 
> > 
> > Pick a name that conveys what the flag is about, and document those
> > semantics well.  This flag is about the fact that for a given file,
> > as long as that file exists in the file system the handle is stable.
> > Both stable and persistent are suitable for that, nfs is everything
> > but.
> 
> My understanding is that kernfs would not get the flag.
> kernfs filehandles do not change as long as the file exist.
> But this is not sufficient for the files to be usefully exported.
> 
> I suspect kernfs does re-use filehandles relatively soon after the
> file/object has been destroyed.  Maybe that is the real problem here:
> filehandle reuse, not filehandle stability.
> 
> Jeff: could you please give details (and preserve them in future cover
> letters) of which filesystems are known to have problems and what
> exactly those problems are?
> 

The only one I'm aware of at the moment is cgroupfs. sb->s_export_op
gets populated on that fs, so it's exportable via nfsd.

Its fs does not show up under the v4 pseudoroot, but you can mount
/sys/fs/cgroup with v3 if it's specifically exported. Directories seem
to work properly (I can ls and cd around in there), but the files all
come back empty when read. I didn't play around with trying to write to
any of them.

I didn't do a lot of investigation here, since I didn't actually expect
it to work properly.

> > 
> > Remember nfs also support volatile file handles, and other applications
> > might rely on this (I know of quite a few user space applications that
> > do, but they are kinda hardwired to xfs anyway).
> 
> The NFS protocol supports volatile file handles.  knfsd does not.
> So maybe
>   EXPORT_OP_NOT_NFSD_COMPATIBLE
> might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> (I prefer opt-out rather than opt-in because nfsd export was the
> original purpose of export_operations, but it isn't something
> I would fight for)
> 

The whole point of this is to make nfsd export an opt-in in. Exporting
via NFS is something that filesystem developers need to consider
carefully.

cgroupfs is not that big a worry. My bigger concern is new filesystems
being added that do add this for local access and become exportable
without vetting that they will actually work correctly (well, that and
FUSE exportability, which is a bigger can of worms).

There is another approach we could consider: We could move the
export_operations that are needed for local filehandle access into a
new struct filehandle_operations or something. It does mean adding an
extra pointer to the super_block for the new operations vector, but it
might be more intuitive.
-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[NeilBrown]

On Mon, 19 Jan 2026, Jeff Layton wrote:
> 
> There is another approach we could consider: We could move the
> export_operations that are needed for local filehandle access into a
> new struct filehandle_operations or something. It does mean adding an
> extra pointer to the super_block for the new operations vector, but it
> might be more intuitive.

If that sort of change were seen to be valuable, I would rather not
create a filehandle_operations but merge some (or all) of
export_operations into super_operations.
Maybe then the existence of s_export_op would return to mean "NFS export
supported" even if it is empty.

Thanks,
NeilBrown

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Chuck Lever]

On Thu, Jan 15, 2026, at 1:17 PM, Amir Goldstein wrote:
> On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@kernel.org> wrote:
>>
>> In recent years, a number of filesystems that can't present stable
>> filehandles have grown struct export_operations. They've mostly done
>> this for local use-cases (enabling open_by_handle_at() and the like).
>> Unfortunately, having export_operations is generally sufficient to make
>> a filesystem be considered exportable via nfsd, but that requires that
>> the server present stable filehandles.
>
> Where does the term "stable file handles" come from? and what does it mean?
> Why not "persistent handles", which is described in NFS and SMB specs?
>
> Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
> by both Christoph and Christian:
>
> https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/
>
> Am I missing anything?

PERSISTENT generally implies that the file handle is saved on
persistent storage. This is not true of tmpfs.

The use of "stable" means that the file handle is stable for
the life of the file. This /is/ true of tmpfs.

-- 
Chuck Lever

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Amir Goldstein]

On Thu, Jan 15, 2026 at 7:32 PM Chuck Lever <cel@kernel.org> wrote:
>
>
>
> On Thu, Jan 15, 2026, at 1:17 PM, Amir Goldstein wrote:
> > On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@kernel.org> wrote:
> >>
> >> In recent years, a number of filesystems that can't present stable
> >> filehandles have grown struct export_operations. They've mostly done
> >> this for local use-cases (enabling open_by_handle_at() and the like).
> >> Unfortunately, having export_operations is generally sufficient to make
> >> a filesystem be considered exportable via nfsd, but that requires that
> >> the server present stable filehandles.
> >
> > Where does the term "stable file handles" come from? and what does it mean?
> > Why not "persistent handles", which is described in NFS and SMB specs?
> >
> > Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
> > by both Christoph and Christian:
> >
> > https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/
> >
> > Am I missing anything?
>
> PERSISTENT generally implies that the file handle is saved on
> persistent storage. This is not true of tmpfs.

That's one way of interpreting "persistent".
Another way is "continuing to exist or occur over a prolonged period."
which works well for tmpfs that is mounted for a long time.

But I am confused, because I went looking for where Jeff said that
you suggested stable file handles and this is what I found that you wrote:

"tmpfs filehandles align quite well with the traditional definition
 of persistent filehandles. tmpfs filehandles live as long as tmpfs files do,
 and that is all that is required to be considered "persistent".

>
> The use of "stable" means that the file handle is stable for
> the life of the file. This /is/ true of tmpfs.

I can live with STABLE_HANDLES I don't mind as much,
I understand what it means, but the definition above is invented,
whereas the term persistent handles is well known and well defined.

Thanks,
Amir.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Amir Goldstein]

On Thu, Jan 15, 2026 at 8:14 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Thu, Jan 15, 2026 at 7:32 PM Chuck Lever <cel@kernel.org> wrote:
> >
> >
> >
> > On Thu, Jan 15, 2026, at 1:17 PM, Amir Goldstein wrote:
> > > On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@kernel.org> wrote:
> > >>
> > >> In recent years, a number of filesystems that can't present stable
> > >> filehandles have grown struct export_operations. They've mostly done
> > >> this for local use-cases (enabling open_by_handle_at() and the like).
> > >> Unfortunately, having export_operations is generally sufficient to make
> > >> a filesystem be considered exportable via nfsd, but that requires that
> > >> the server present stable filehandles.
> > >
> > > Where does the term "stable file handles" come from? and what does it mean?
> > > Why not "persistent handles", which is described in NFS and SMB specs?
> > >
> > > Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
> > > by both Christoph and Christian:
> > >
> > > https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/
> > >
> > > Am I missing anything?
> >
> > PERSISTENT generally implies that the file handle is saved on
> > persistent storage. This is not true of tmpfs.
>
> That's one way of interpreting "persistent".
> Another way is "continuing to exist or occur over a prolonged period."
> which works well for tmpfs that is mounted for a long time.
>
> But I am confused, because I went looking for where Jeff said that
> you suggested stable file handles and this is what I found that you wrote:
>
> "tmpfs filehandles align quite well with the traditional definition
>  of persistent filehandles. tmpfs filehandles live as long as tmpfs files do,
>  and that is all that is required to be considered "persistent".
>
> >
> > The use of "stable" means that the file handle is stable for
> > the life of the file. This /is/ true of tmpfs.
>
> I can live with STABLE_HANDLES I don't mind as much,
> I understand what it means, but the definition above is invented,
> whereas the term persistent handles is well known and well defined.
>

And also forgot to mention - STABLE HANDLES is very lexicographically
close to STALE HANDLES :-/

Thanks,
Amir.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Chuck Lever]

On 1/15/26 2:14 PM, Amir Goldstein wrote:
> On Thu, Jan 15, 2026 at 7:32 PM Chuck Lever <cel@kernel.org> wrote:
>>
>>
>>
>> On Thu, Jan 15, 2026, at 1:17 PM, Amir Goldstein wrote:
>>> On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@kernel.org> wrote:
>>>>
>>>> In recent years, a number of filesystems that can't present stable
>>>> filehandles have grown struct export_operations. They've mostly done
>>>> this for local use-cases (enabling open_by_handle_at() and the like).
>>>> Unfortunately, having export_operations is generally sufficient to make
>>>> a filesystem be considered exportable via nfsd, but that requires that
>>>> the server present stable filehandles.
>>>
>>> Where does the term "stable file handles" come from? and what does it mean?
>>> Why not "persistent handles", which is described in NFS and SMB specs?
>>>
>>> Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
>>> by both Christoph and Christian:
>>>
>>> https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/
>>>
>>> Am I missing anything?
>>
>> PERSISTENT generally implies that the file handle is saved on
>> persistent storage. This is not true of tmpfs.
> 
> That's one way of interpreting "persistent".
> Another way is "continuing to exist or occur over a prolonged period."
> which works well for tmpfs that is mounted for a long time.

I think we can be a lot more precise about the guarantee: The file
handle does not change for the life of the inode it represents. It
has nothing to do with whether the file system is mounted.


> But I am confused, because I went looking for where Jeff said that
> you suggested stable file handles and this is what I found that you wrote:
> 
> "tmpfs filehandles align quite well with the traditional definition
>  of persistent filehandles. tmpfs filehandles live as long as tmpfs files do,
>  and that is all that is required to be considered "persistent".

I changed my mind about the name, and I let Jeff know that privately
when he asked me to look at these patches this morning.


>> The use of "stable" means that the file handle is stable for
>> the life of the file. This /is/ true of tmpfs.
> 
> I can live with STABLE_HANDLES I don't mind as much,
> I understand what it means, but the definition above is invented,
> whereas the term persistent handles is well known and well defined.

Another reason not to adopt the same terminology as NFS is that
someone might come along and implement NFSv4's VOLATILE file
handles in Linux, and then say "OK, /now/ can we export cgroupfs?"
And then Linux will be stuck with overloaded terminology and we'll
still want to say "NO, NFS doesn't support cgroupfs".

Just a random thought.


-- 
Chuck Lever

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Amir Goldstein]

On Thu, Jan 15, 2026 at 8:37 PM Chuck Lever <cel@kernel.org> wrote:
>
> On 1/15/26 2:14 PM, Amir Goldstein wrote:
> > On Thu, Jan 15, 2026 at 7:32 PM Chuck Lever <cel@kernel.org> wrote:
> >>
> >>
> >>
> >> On Thu, Jan 15, 2026, at 1:17 PM, Amir Goldstein wrote:
> >>> On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@kernel.org> wrote:
> >>>>
> >>>> In recent years, a number of filesystems that can't present stable
> >>>> filehandles have grown struct export_operations. They've mostly done
> >>>> this for local use-cases (enabling open_by_handle_at() and the like).
> >>>> Unfortunately, having export_operations is generally sufficient to make
> >>>> a filesystem be considered exportable via nfsd, but that requires that
> >>>> the server present stable filehandles.
> >>>
> >>> Where does the term "stable file handles" come from? and what does it mean?
> >>> Why not "persistent handles", which is described in NFS and SMB specs?
> >>>
> >>> Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
> >>> by both Christoph and Christian:
> >>>
> >>> https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/
> >>>
> >>> Am I missing anything?
> >>
> >> PERSISTENT generally implies that the file handle is saved on
> >> persistent storage. This is not true of tmpfs.
> >
> > That's one way of interpreting "persistent".
> > Another way is "continuing to exist or occur over a prolonged period."
> > which works well for tmpfs that is mounted for a long time.
>
> I think we can be a lot more precise about the guarantee: The file
> handle does not change for the life of the inode it represents. It
> has nothing to do with whether the file system is mounted.
>
>
> > But I am confused, because I went looking for where Jeff said that
> > you suggested stable file handles and this is what I found that you wrote:
> >
> > "tmpfs filehandles align quite well with the traditional definition
> >  of persistent filehandles. tmpfs filehandles live as long as tmpfs files do,
> >  and that is all that is required to be considered "persistent".
>
> I changed my mind about the name, and I let Jeff know that privately
> when he asked me to look at these patches this morning.
>
>
> >> The use of "stable" means that the file handle is stable for
> >> the life of the file. This /is/ true of tmpfs.
> >
> > I can live with STABLE_HANDLES I don't mind as much,
> > I understand what it means, but the definition above is invented,
> > whereas the term persistent handles is well known and well defined.
>
> Another reason not to adopt the same terminology as NFS is that
> someone might come along and implement NFSv4's VOLATILE file
> handles in Linux, and then say "OK, /now/ can we export cgroupfs?"
> And then Linux will be stuck with overloaded terminology and we'll
> still want to say "NO, NFS doesn't support cgroupfs".
>
> Just a random thought.

Good argument. I'm fine with stable as well :)

Thanks,
Amir.

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Dave Chinner]

On Thu, Jan 15, 2026 at 02:37:09PM -0500, Chuck Lever wrote:
> On 1/15/26 2:14 PM, Amir Goldstein wrote:
> > On Thu, Jan 15, 2026 at 7:32 PM Chuck Lever <cel@kernel.org> wrote:
> >>
> >>
> >>
> >> On Thu, Jan 15, 2026, at 1:17 PM, Amir Goldstein wrote:
> >>> On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@kernel.org> wrote:
> >>>>
> >>>> In recent years, a number of filesystems that can't present stable
> >>>> filehandles have grown struct export_operations. They've mostly done
> >>>> this for local use-cases (enabling open_by_handle_at() and the like).
> >>>> Unfortunately, having export_operations is generally sufficient to make
> >>>> a filesystem be considered exportable via nfsd, but that requires that
> >>>> the server present stable filehandles.
> >>>
> >>> Where does the term "stable file handles" come from? and what does it mean?
> >>> Why not "persistent handles", which is described in NFS and SMB specs?
> >>>
> >>> Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
> >>> by both Christoph and Christian:
> >>>
> >>> https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/
> >>>
> >>> Am I missing anything?
> >>
> >> PERSISTENT generally implies that the file handle is saved on
> >> persistent storage. This is not true of tmpfs.
> > 
> > That's one way of interpreting "persistent".
> > Another way is "continuing to exist or occur over a prolonged period."
> > which works well for tmpfs that is mounted for a long time.
> 
> I think we can be a lot more precise about the guarantee: The file
> handle does not change for the life of the inode it represents. It

<pedantic mode engaged>

File handles most definitely change over the life of a /physical/
inode. Unlinking a file does not require ending the life of the
physical object that provides the persistent data store for the
file.

e.g. XFS dynamically allocates physical inodes might in a life cycle
that looks somewhat life this:

	allocate physical inode
	insert record into allocated inode index
	mark inode as free

	while (don't need to free physical inode) {
		...
		allocate inode for a new file
		update persistent inode metadata to generate new filehandle
		mark inode in use
		...
		unlink file
		mark inode free
	}

	remove inode from allocated inode index
	free physical inode

i.e. a free inode is still an -allocated, indexed inode- in the
filesystem, and until we physically remove it from the filesystem
the inode life cycle has not ended.

IOWs, the physical (persistent) inode lifetime can span the lifetime
of -many- files. However, the filesystem guarantees that the handle
generated for that inode is different for each file it represents
over the whole inode life time.

Hence I think that file handle stability/persistence needs to be
defined in terms of -file lifetimes-, not the lifetimes of the
filesystem objects implement the file's persistent data store.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Chuck Lever]

On Thu, Jan 15, 2026, at 4:09 PM, Dave Chinner wrote:
> On Thu, Jan 15, 2026 at 02:37:09PM -0500, Chuck Lever wrote:
>> On 1/15/26 2:14 PM, Amir Goldstein wrote:
>> > On Thu, Jan 15, 2026 at 7:32 PM Chuck Lever <cel@kernel.org> wrote:
>> >>
>> >>
>> >>
>> >> On Thu, Jan 15, 2026, at 1:17 PM, Amir Goldstein wrote:
>> >>> On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@kernel.org> wrote:
>> >>>>
>> >>>> In recent years, a number of filesystems that can't present stable
>> >>>> filehandles have grown struct export_operations. They've mostly done
>> >>>> this for local use-cases (enabling open_by_handle_at() and the like).
>> >>>> Unfortunately, having export_operations is generally sufficient to make
>> >>>> a filesystem be considered exportable via nfsd, but that requires that
>> >>>> the server present stable filehandles.
>> >>>
>> >>> Where does the term "stable file handles" come from? and what does it mean?
>> >>> Why not "persistent handles", which is described in NFS and SMB specs?
>> >>>
>> >>> Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
>> >>> by both Christoph and Christian:
>> >>>
>> >>> https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/
>> >>>
>> >>> Am I missing anything?
>> >>
>> >> PERSISTENT generally implies that the file handle is saved on
>> >> persistent storage. This is not true of tmpfs.
>> > 
>> > That's one way of interpreting "persistent".
>> > Another way is "continuing to exist or occur over a prolonged period."
>> > which works well for tmpfs that is mounted for a long time.
>> 
>> I think we can be a lot more precise about the guarantee: The file
>> handle does not change for the life of the inode it represents. It
>
> <pedantic mode engaged>
>
> File handles most definitely change over the life of a /physical/
> inode. Unlinking a file does not require ending the life of the
> physical object that provides the persistent data store for the
> file.
>
> e.g. XFS dynamically allocates physical inodes might in a life cycle
> that looks somewhat life this:
>
> 	allocate physical inode
> 	insert record into allocated inode index
> 	mark inode as free
>
> 	while (don't need to free physical inode) {
> 		...
> 		allocate inode for a new file
> 		update persistent inode metadata to generate new filehandle
> 		mark inode in use
> 		...
> 		unlink file
> 		mark inode free
> 	}
>
> 	remove inode from allocated inode index
> 	free physical inode
>
> i.e. a free inode is still an -allocated, indexed inode- in the
> filesystem, and until we physically remove it from the filesystem
> the inode life cycle has not ended.
>
> IOWs, the physical (persistent) inode lifetime can span the lifetime
> of -many- files. However, the filesystem guarantees that the handle
> generated for that inode is different for each file it represents
> over the whole inode life time.
>
> Hence I think that file handle stability/persistence needs to be
> defined in terms of -file lifetimes-, not the lifetimes of the
> filesystem objects implement the file's persistent data store.

Fair enough, "inode" is the wrong term to use here.


-- 
Chuck Lever

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[David Laight]

On Thu, 15 Jan 2026 16:37:27 -0500
"Chuck Lever" <cel@kernel.org> wrote:

> On Thu, Jan 15, 2026, at 4:09 PM, Dave Chinner wrote:
> > On Thu, Jan 15, 2026 at 02:37:09PM -0500, Chuck Lever wrote:  
> >> On 1/15/26 2:14 PM, Amir Goldstein wrote:  
> >> > On Thu, Jan 15, 2026 at 7:32 PM Chuck Lever <cel@kernel.org> wrote:  
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Jan 15, 2026, at 1:17 PM, Amir Goldstein wrote:  
> >> >>> On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@kernel.org> wrote:  
> >> >>>>
> >> >>>> In recent years, a number of filesystems that can't present stable
> >> >>>> filehandles have grown struct export_operations. They've mostly done
> >> >>>> this for local use-cases (enabling open_by_handle_at() and the like).
> >> >>>> Unfortunately, having export_operations is generally sufficient to make
> >> >>>> a filesystem be considered exportable via nfsd, but that requires that
> >> >>>> the server present stable filehandles.  
> >> >>>
> >> >>> Where does the term "stable file handles" come from? and what does it mean?
> >> >>> Why not "persistent handles", which is described in NFS and SMB specs?
> >> >>>
> >> >>> Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
> >> >>> by both Christoph and Christian:
> >> >>>
> >> >>> https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/
> >> >>>
> >> >>> Am I missing anything?  
> >> >>
> >> >> PERSISTENT generally implies that the file handle is saved on
> >> >> persistent storage. This is not true of tmpfs.  
> >> > 
> >> > That's one way of interpreting "persistent".
> >> > Another way is "continuing to exist or occur over a prolonged period."
> >> > which works well for tmpfs that is mounted for a long time.  
> >> 
> >> I think we can be a lot more precise about the guarantee: The file
> >> handle does not change for the life of the inode it represents. It  
> >
> > <pedantic mode engaged>
> >
> > File handles most definitely change over the life of a /physical/
> > inode. Unlinking a file does not require ending the life of the
> > physical object that provides the persistent data store for the
> > file.
> >
> > e.g. XFS dynamically allocates physical inodes might in a life cycle
> > that looks somewhat life this:
> >
> > 	allocate physical inode
> > 	insert record into allocated inode index
> > 	mark inode as free
> >
> > 	while (don't need to free physical inode) {
> > 		...
> > 		allocate inode for a new file
> > 		update persistent inode metadata to generate new filehandle
> > 		mark inode in use
> > 		...
> > 		unlink file
> > 		mark inode free
> > 	}
> >
> > 	remove inode from allocated inode index
> > 	free physical inode
> >
> > i.e. a free inode is still an -allocated, indexed inode- in the
> > filesystem, and until we physically remove it from the filesystem
> > the inode life cycle has not ended.
> >
> > IOWs, the physical (persistent) inode lifetime can span the lifetime
> > of -many- files. However, the filesystem guarantees that the handle
> > generated for that inode is different for each file it represents
> > over the whole inode life time.
> >
> > Hence I think that file handle stability/persistence needs to be
> > defined in terms of -file lifetimes-, not the lifetimes of the
> > filesystem objects implement the file's persistent data store.  
> 
> Fair enough, "inode" is the wrong term to use here.

Usually there is 'generation number' changes when the inode is used for
a new file.
IIRC the original nfs file handle was the major/minor for the disk partition,
the index into the 'on-disk inode table' (the inode number) and the
'generation number' (but I'm sure the length was a power of 2...).

It's not surprising Unix uses inode number and file handles.
K&R would have used RSM-11/M where 'file directory lookup' was a userspace
operation and the kernel only supported 'open by file handle'.
Although that got lost between there and ntfs.
(Windows IO is definitely based on RSM-11/M though.)

	David

Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Christoph Hellwig]

On Fri, Jan 16, 2026 at 08:09:16AM +1100, Dave Chinner wrote:
> > I think we can be a lot more precise about the guarantee: The file
> > handle does not change for the life of the inode it represents. It
> 
> <pedantic mode engaged>
> 
> File handles most definitely change over the life of a /physical/
> inode. Unlinking a file does not require ending the life of the
> physical object that provides the persistent data store for the
> file.

> i.e. a free inode is still an -allocated, indexed inode- in the
> filesystem, and until we physically remove it from the filesystem
> the inode life cycle has not ended.

For other file systems like ext4 that have statically allocated
inodes that is even more so the case.

> IOWs, the physical (persistent) inode lifetime can span the lifetime
> of -many- files. However, the filesystem guarantees that the handle
> generated for that inode is different for each file it represents
> over the whole inode life time.
> 
> Hence I think that file handle stability/persistence needs to be
> defined in terms of -file lifetimes-, not the lifetimes of the
> filesystem objects implement the file's persistent data store.

Agreed, although I bet that is what most folks think of for the
inode - not a physical place on disk, but an object that gets
invalidated on the last close after unlink.  Either way, that rules
do need to be written down clearly.