On Mon, Jan 19, 2026 at 5:27 PM Jeff Layton <[email protected]> wrote: > > At one time, nfsd could take the presence of struct export_operations to > be an indicator that a filesystem was exportable via NFS. Since then, a > lot of filesystems have grown export operations in order to provide > filehandle support. Some of those (e.g. kernfs, pidfs, and nsfs) are not > suitable for export via NFS since they lack filehandles that are > stable across reboot. > > Add a new EXPORT_OP_STABLE_HANDLES flag that indicates that the > filesystem supports perisistent filehandles,
persistent still here? "...are stable across the lifetime of a file"? > a requirement for nfs > export. While in there, switch to the BIT() macro for defining these > flags. Maybe you want to move that cleanup to patch 1 along with the export.rst sync? not a must. > > For now, the flag is not checked anywhere. That will come later after > we've added it to the existing filesystems that need to remain > exportable. > > Reviewed-by: Jan Kara <[email protected]> > Signed-off-by: Jeff Layton <[email protected]> > --- > Documentation/filesystems/nfs/exporting.rst | 7 +++++++ > include/linux/exportfs.h | 16 +++++++++------- > 2 files changed, 16 insertions(+), 7 deletions(-) > > diff --git a/Documentation/filesystems/nfs/exporting.rst > b/Documentation/filesystems/nfs/exporting.rst > index > 0583a0516b1e3a3e6a10af95ff88506cf02f7df4..0c29ee44e3484cef84d2d3d47819acf172d275a3 > 100644 > --- a/Documentation/filesystems/nfs/exporting.rst > +++ b/Documentation/filesystems/nfs/exporting.rst > @@ -244,3 +244,10 @@ following flags are defined: > nfsd. A case in point is reexport of NFS itself, which can't be done > safely without coordinating the grace period handling. Other clustered > and networked filesystems can be problematic here as well. > + > + EXPORT_OP_STABLE_HANDLES - This filesystem provides filehandles that are > + stable across the lifetime of a file. This is a hard requirement for > export > + via nfsd. Any filesystem that is eligible to be exported via nfsd must > + indicate this guarantee by setting this flag. Most disk-based filesystems > + can do this naturally. Pseudofilesystems that are for local reporting and > + control (e.g. kernfs, pidfs, nsfs) usually can't support this. > diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h > index > f0cf2714ec52dd942b8f1c455a25702bd7e412b3..c4e0f083290e7e341342cf0b45b58fddda3af65e > 100644 > --- a/include/linux/exportfs.h > +++ b/include/linux/exportfs.h > @@ -3,6 +3,7 @@ > #define LINUX_EXPORTFS_H 1 > > #include <linux/types.h> > +#include <linux/bits.h> > #include <linux/path.h> > > struct dentry; > @@ -277,15 +278,16 @@ struct export_operations { > int nr_iomaps, struct iattr *iattr); > int (*permission)(struct handle_to_path_ctx *ctx, unsigned int > oflags); > struct file * (*open)(const struct path *path, unsigned int oflags); > -#define EXPORT_OP_NOWCC (0x1) /* don't collect v3 wcc > data */ > -#define EXPORT_OP_NOSUBTREECHK (0x2) /* no subtree checking > */ > -#define EXPORT_OP_CLOSE_BEFORE_UNLINK (0x4) /* close files before > unlink */ > -#define EXPORT_OP_REMOTE_FS (0x8) /* Filesystem is remote */ > -#define EXPORT_OP_NOATOMIC_ATTR (0x10) /* Filesystem cannot > supply > +#define EXPORT_OP_NOWCC BIT(0) /* don't collect v3 > wcc data */ > +#define EXPORT_OP_NOSUBTREECHK BIT(1) /* no subtree checking */ > +#define EXPORT_OP_CLOSE_BEFORE_UNLINK BIT(2) /* close files before unlink */ > +#define EXPORT_OP_REMOTE_FS BIT(3) /* Filesystem is remote */ > +#define EXPORT_OP_NOATOMIC_ATTR BIT(4) /* Filesystem cannot > supply > atomic attribute updates > */ > -#define EXPORT_OP_FLUSH_ON_CLOSE (0x20) /* fs flushes file data on > close */ > -#define EXPORT_OP_NOLOCKS (0x40) /* no file locking support */ > +#define EXPORT_OP_FLUSH_ON_CLOSE BIT(5) /* fs flushes file data on > close */ > +#define EXPORT_OP_NOLOCKS BIT(6) /* no file locking support */ > +#define EXPORT_OP_STABLE_HANDLES BIT(7) /* fhs are stable across > reboot */ > unsigned long flags; > }; > > > -- > 2.52.0 >
