[PATCH v3 0/2] nfsd and special kernel filesystems

[PATCH v3 0/2] nfsd and special kernel filesystems

[Amir Goldstein]

Christian,

I noticed that the kernel-doc refactoring queued on vfs-7.0.misc was
going to conflict with v2 [1], so I rebased over vfs-7.0.misc and split
it into doc update and nfsd fix patch that could be backported.

RVBs by Chuck and Jeff were removed due to the slight changes in wording.

I'd like to acknowledge that Christoph wrote on v2 that:
"As last time I'd be happy to help write documentation, but even
 after looking at the methods, their documentations and the commits
 adding them I do not understand them.  So getting an explanation
 from Christian would be really helpful to move forward here."

IMO, further clarifications of the new methods is very much welcome,
but should not be blocking the merge of this patch set, which at least
clarifies the WHAT (to use them for) if not the HOW (to use them).

Thanks,
Amir.

Changes since v2:
- Rebase over vfs-7.0.misc
- Split to doc/fix patches
- Remove RVBs

[1] https://lore.kernel.org/linux-fsdevel/20260122141942.660948-1-amir73il@gmail.com/

Amir Goldstein (2):
  exportfs: clarify the documentation of open()/permission() expotrfs
    ops
  nfsd: do not allow exporting of special kernel filesystems

 fs/nfsd/export.c         |  8 +++++---
 include/linux/exportfs.h | 25 ++++++++++++++++++++++---
 2 files changed, 27 insertions(+), 6 deletions(-)

-- 
2.52.0

[PATCH v3 1/2] exportfs: clarify the documentation of open()/permission() expotrfs ops

[Amir Goldstein]

pidfs and nsfs recently gained support for encode/decode of file handles
via name_to_handle_at(2)/opan_by_handle_at(2).

These special kernel filesystems have custom ->open() and ->permission()
export methods, which nfsd does not respect and it was never meant to be
used for exporting those filesystems by nfsd.

Update kernel-doc comments to express the fact the those methods are for
open_by_handle(2) system only and not compatible with nfsd.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 include/linux/exportfs.h | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
index 262e24d833134..fafd22ed4c648 100644
--- a/include/linux/exportfs.h
+++ b/include/linux/exportfs.h
@@ -192,7 +192,9 @@ struct handle_to_path_ctx {
 #define FILEID_VALID_USER_FLAGS	(FILEID_IS_CONNECTABLE | FILEID_IS_DIR)
 
 /**
- * struct export_operations - for nfsd to communicate with file systems
+ * struct export_operations
+ *
+ * Methods for nfsd to communicate with file systems:
  * @encode_fh:      encode a file handle fragment from a dentry
  * @fh_to_dentry:   find the implied object and get a dentry for it
  * @fh_to_parent:   find the implied object's parent and get a dentry for it
@@ -200,6 +202,10 @@ struct handle_to_path_ctx {
  * @get_parent:     find the parent of a given directory
  * @commit_metadata: commit metadata changes to stable storage
  *
+ * Methods for open_by_handle(2) syscall with special kernel file systems:
+ * @permission:     custom permission for opening a file by handle
+ * @open:           custom open routine for opening file by handle
+ *
  * See Documentation/filesystems/nfs/exporting.rst for details on how to use
  * this interface correctly and the definition of the flags.
  *
@@ -244,10 +250,14 @@ struct handle_to_path_ctx {
  *    space cannot be allocated, a %ERR_PTR should be returned.
  *
  * @permission:
- *    Allow filesystems to specify a custom permission function.
+ *    Allow filesystems to specify a custom permission function for the
+ *    open_by_handle_at(2) syscall instead of the default permission check.
+ *    This custom permission function is not respected by nfsd.
  *
  * @open:
- *    Allow filesystems to specify a custom open function.
+ *    Allow filesystems to specify a custom open function for the
+ *    open_by_handle_at(2) syscall instead of the default file_open_root().
+ *    This custom open function is not respected by nfsd.
  *
  * @commit_metadata:
  *    @commit_metadata should commit metadata changes to stable storage.
-- 
2.52.0

Re: [PATCH v3 1/2] exportfs: clarify the documentation of open()/permission() expotrfs ops

[Chuck Lever]

Typo in Subject: s/expotrfs/exportfs


On Wed, Jan 28, 2026, at 6:16 AM, Amir Goldstein wrote:
> pidfs and nsfs recently gained support for encode/decode of file handles
> via name_to_handle_at(2)/opan_by_handle_at(2).

s/opan/open

And one more below:


> These special kernel filesystems have custom ->open() and ->permission()
> export methods, which nfsd does not respect and it was never meant to be
> used for exporting those filesystems by nfsd.
>
> Update kernel-doc comments to express the fact the those methods are for
> open_by_handle(2) system only and not compatible with nfsd.
>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>  include/linux/exportfs.h | 16 +++++++++++++---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
> index 262e24d833134..fafd22ed4c648 100644
> --- a/include/linux/exportfs.h
> +++ b/include/linux/exportfs.h
> @@ -192,7 +192,9 @@ struct handle_to_path_ctx {
>  #define FILEID_VALID_USER_FLAGS	(FILEID_IS_CONNECTABLE | FILEID_IS_DIR)
> 
>  /**
> - * struct export_operations - for nfsd to communicate with file systems
> + * struct export_operations
> + *
> + * Methods for nfsd to communicate with file systems:

Let's not remove the brief description for the export_operations
struct in the Doxygen output.


>   * @encode_fh:      encode a file handle fragment from a dentry
>   * @fh_to_dentry:   find the implied object and get a dentry for it
>   * @fh_to_parent:   find the implied object's parent and get a dentry for it
> @@ -200,6 +202,10 @@ struct handle_to_path_ctx {
>   * @get_parent:     find the parent of a given directory
>   * @commit_metadata: commit metadata changes to stable storage
>   *
> + * Methods for open_by_handle(2) syscall with special kernel file systems:
> + * @permission:     custom permission for opening a file by handle
> + * @open:           custom open routine for opening file by handle
> + *
>   * See Documentation/filesystems/nfs/exporting.rst for details on how to use
>   * this interface correctly and the definition of the flags.
>   *
> @@ -244,10 +250,14 @@ struct handle_to_path_ctx {
>   *    space cannot be allocated, a %ERR_PTR should be returned.
>   *
>   * @permission:
> - *    Allow filesystems to specify a custom permission function.
> + *    Allow filesystems to specify a custom permission function for the
> + *    open_by_handle_at(2) syscall instead of the default permission check.
> + *    This custom permission function is not respected by nfsd.
>   *
>   * @open:
> - *    Allow filesystems to specify a custom open function.
> + *    Allow filesystems to specify a custom open function for the
> + *    open_by_handle_at(2) syscall instead of the default file_open_root().
> + *    This custom open function is not respected by nfsd.
>   *
>   * @commit_metadata:
>   *    @commit_metadata should commit metadata changes to stable storage.
> -- 
> 2.52.0

-- 
Chuck Lever

Re: [PATCH v3 1/2] exportfs: clarify the documentation of open()/permission() expotrfs ops

[Amir Goldstein]

On Wed, Jan 28, 2026 at 5:10 PM Chuck Lever <cel@kernel.org> wrote:
>
> Typo in Subject: s/expotrfs/exportfs
>
>
> On Wed, Jan 28, 2026, at 6:16 AM, Amir Goldstein wrote:
> > pidfs and nsfs recently gained support for encode/decode of file handles
> > via name_to_handle_at(2)/opan_by_handle_at(2).
>
> s/opan/open
>
> And one more below:
>
>
> > These special kernel filesystems have custom ->open() and ->permission()
> > export methods, which nfsd does not respect and it was never meant to be
> > used for exporting those filesystems by nfsd.
> >
> > Update kernel-doc comments to express the fact the those methods are for
> > open_by_handle(2) system only and not compatible with nfsd.
> >
> > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > ---
> >  include/linux/exportfs.h | 16 +++++++++++++---
> >  1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
> > index 262e24d833134..fafd22ed4c648 100644
> > --- a/include/linux/exportfs.h
> > +++ b/include/linux/exportfs.h
> > @@ -192,7 +192,9 @@ struct handle_to_path_ctx {
> >  #define FILEID_VALID_USER_FLAGS      (FILEID_IS_CONNECTABLE | FILEID_IS_DIR)
> >
> >  /**
> > - * struct export_operations - for nfsd to communicate with file systems
> > + * struct export_operations
> > + *
> > + * Methods for nfsd to communicate with file systems:
>
> Let's not remove the brief description for the export_operations
> struct in the Doxygen output.
>

OK. will fix for v4.

Thanks,
Amir.

[PATCH v3 2/2] nfsd: do not allow exporting of special kernel filesystems

[Amir Goldstein]

pidfs and nsfs recently gained support for encode/decode of file handles
via name_to_handle_at(2)/opan_by_handle_at(2).

These special kernel filesystems have custom ->open() and ->permission()
export methods, which nfsd does not respect and it was never meant to be
used for exporting those filesystems by nfsd.

Therefore, do not allow nfsd to export filesystems with custom ->open()
or ->permission() methods.

Fixes: b3caba8f7a34a ("pidfs: implement file handle support")
Fixes: 5222470b2fbb3 ("nsfs: support file handles")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 fs/nfsd/export.c         | 8 +++++---
 include/linux/exportfs.h | 9 +++++++++
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
index 2a1499f2ad196..09fe268fe2c76 100644
--- a/fs/nfsd/export.c
+++ b/fs/nfsd/export.c
@@ -427,7 +427,8 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
 	 *       either a device number (so FS_REQUIRES_DEV needed)
 	 *       or an FSID number (so NFSEXP_FSID or ->uuid is needed).
 	 * 2:  We must be able to find an inode from a filehandle.
-	 *       This means that s_export_op must be set.
+	 *       This means that s_export_op must be set and comply with
+	 *       the requirements for remote filesystem export.
 	 * 3: We must not currently be on an idmapped mount.
 	 */
 	if (!(inode->i_sb->s_type->fs_flags & FS_REQUIRES_DEV) &&
@@ -437,8 +438,9 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
 		return -EINVAL;
 	}
 
-	if (!exportfs_can_decode_fh(inode->i_sb->s_export_op)) {
-		dprintk("exp_export: export of invalid fs type.\n");
+	if (!exportfs_may_export(inode->i_sb->s_export_op)) {
+		dprintk("exp_export: export of invalid fs type (%s).\n",
+			inode->i_sb->s_type->name);
 		return -EINVAL;
 	}
 
diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
index fafd22ed4c648..bf3dee2ad5f97 100644
--- a/include/linux/exportfs.h
+++ b/include/linux/exportfs.h
@@ -340,6 +340,15 @@ static inline bool exportfs_can_decode_fh(const struct export_operations *nop)
 	return nop && nop->fh_to_dentry;
 }
 
+static inline bool exportfs_may_export(const struct export_operations *nop)
+{
+	/*
+	 * Do not allow nfs export for filesystems with custom ->open() and
+	 * ->permission() ops, which nfsd does not respect (e.g. pidfs, nsfs).
+	 */
+	return exportfs_can_decode_fh(nop) && !nop->open && !nop->permission;
+}
+
 static inline bool exportfs_can_encode_fh(const struct export_operations *nop,
 					  int fh_flags)
 {
-- 
2.52.0

Re: [PATCH v3 2/2] nfsd: do not allow exporting of special kernel filesystems

[Chuck Lever]

On Wed, Jan 28, 2026, at 6:16 AM, Amir Goldstein wrote:
> pidfs and nsfs recently gained support for encode/decode of file handles
> via name_to_handle_at(2)/opan_by_handle_at(2).

s/opan/open

One more below:


> These special kernel filesystems have custom ->open() and ->permission()
> export methods, which nfsd does not respect and it was never meant to be
> used for exporting those filesystems by nfsd.
>
> Therefore, do not allow nfsd to export filesystems with custom ->open()
> or ->permission() methods.
>
> Fixes: b3caba8f7a34a ("pidfs: implement file handle support")
> Fixes: 5222470b2fbb3 ("nsfs: support file handles")
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>  fs/nfsd/export.c         | 8 +++++---
>  include/linux/exportfs.h | 9 +++++++++
>  2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
> index 2a1499f2ad196..09fe268fe2c76 100644
> --- a/fs/nfsd/export.c
> +++ b/fs/nfsd/export.c
> @@ -427,7 +427,8 @@ static int check_export(const struct path *path, 
> int *flags, unsigned char *uuid
>  	 *       either a device number (so FS_REQUIRES_DEV needed)
>  	 *       or an FSID number (so NFSEXP_FSID or ->uuid is needed).
>  	 * 2:  We must be able to find an inode from a filehandle.
> -	 *       This means that s_export_op must be set.
> +	 *       This means that s_export_op must be set and comply with
> +	 *       the requirements for remote filesystem export.
>  	 * 3: We must not currently be on an idmapped mount.
>  	 */
>  	if (!(inode->i_sb->s_type->fs_flags & FS_REQUIRES_DEV) &&
> @@ -437,8 +438,9 @@ static int check_export(const struct path *path, 
> int *flags, unsigned char *uuid
>  		return -EINVAL;
>  	}
> 
> -	if (!exportfs_can_decode_fh(inode->i_sb->s_export_op)) {
> -		dprintk("exp_export: export of invalid fs type.\n");
> +	if (!exportfs_may_export(inode->i_sb->s_export_op)) {
> +		dprintk("exp_export: export of invalid fs type (%s).\n",
> +			inode->i_sb->s_type->name);
>  		return -EINVAL;
>  	}
> 
> diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
> index fafd22ed4c648..bf3dee2ad5f97 100644
> --- a/include/linux/exportfs.h
> +++ b/include/linux/exportfs.h
> @@ -340,6 +340,15 @@ static inline bool exportfs_can_decode_fh(const 
> struct export_operations *nop)
>  	return nop && nop->fh_to_dentry;
>  }
> 
> +static inline bool exportfs_may_export(const struct export_operations *nop)
> +{
> +	/*
> +	 * Do not allow nfs export for filesystems with custom ->open() and
> +	 * ->permission() ops, which nfsd does not respect (e.g. pidfs, nsfs).
> +	 */

The comment says "with custom ->open() and ->permission() ops" but the
code blocks export if either one is set. The commit message correctly
says "or" - should the comment be updated to match?


> +	return exportfs_can_decode_fh(nop) && !nop->open && !nop->permission;
> +}
> +
>  static inline bool exportfs_can_encode_fh(const struct export_operations *nop,
>  					  int fh_flags)
>  {
> -- 
> 2.52.0

-- 
Chuck Lever

Re: [PATCH v3 2/2] nfsd: do not allow exporting of special kernel filesystems

[Amir Goldstein]

On Wed, Jan 28, 2026 at 5:12 PM Chuck Lever <cel@kernel.org> wrote:
>
>
>
> On Wed, Jan 28, 2026, at 6:16 AM, Amir Goldstein wrote:
> > pidfs and nsfs recently gained support for encode/decode of file handles
> > via name_to_handle_at(2)/opan_by_handle_at(2).
>
> s/opan/open
>
> One more below:
>
>
> > These special kernel filesystems have custom ->open() and ->permission()
> > export methods, which nfsd does not respect and it was never meant to be
> > used for exporting those filesystems by nfsd.
> >
> > Therefore, do not allow nfsd to export filesystems with custom ->open()
> > or ->permission() methods.
> >
> > Fixes: b3caba8f7a34a ("pidfs: implement file handle support")
> > Fixes: 5222470b2fbb3 ("nsfs: support file handles")
> > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > ---
> >  fs/nfsd/export.c         | 8 +++++---
> >  include/linux/exportfs.h | 9 +++++++++
> >  2 files changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
> > index 2a1499f2ad196..09fe268fe2c76 100644
> > --- a/fs/nfsd/export.c
> > +++ b/fs/nfsd/export.c
> > @@ -427,7 +427,8 @@ static int check_export(const struct path *path,
> > int *flags, unsigned char *uuid
> >        *       either a device number (so FS_REQUIRES_DEV needed)
> >        *       or an FSID number (so NFSEXP_FSID or ->uuid is needed).
> >        * 2:  We must be able to find an inode from a filehandle.
> > -      *       This means that s_export_op must be set.
> > +      *       This means that s_export_op must be set and comply with
> > +      *       the requirements for remote filesystem export.
> >        * 3: We must not currently be on an idmapped mount.
> >        */
> >       if (!(inode->i_sb->s_type->fs_flags & FS_REQUIRES_DEV) &&
> > @@ -437,8 +438,9 @@ static int check_export(const struct path *path,
> > int *flags, unsigned char *uuid
> >               return -EINVAL;
> >       }
> >
> > -     if (!exportfs_can_decode_fh(inode->i_sb->s_export_op)) {
> > -             dprintk("exp_export: export of invalid fs type.\n");
> > +     if (!exportfs_may_export(inode->i_sb->s_export_op)) {
> > +             dprintk("exp_export: export of invalid fs type (%s).\n",
> > +                     inode->i_sb->s_type->name);
> >               return -EINVAL;
> >       }
> >
> > diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
> > index fafd22ed4c648..bf3dee2ad5f97 100644
> > --- a/include/linux/exportfs.h
> > +++ b/include/linux/exportfs.h
> > @@ -340,6 +340,15 @@ static inline bool exportfs_can_decode_fh(const
> > struct export_operations *nop)
> >       return nop && nop->fh_to_dentry;
> >  }
> >
> > +static inline bool exportfs_may_export(const struct export_operations *nop)
> > +{
> > +     /*
> > +      * Do not allow nfs export for filesystems with custom ->open() and
> > +      * ->permission() ops, which nfsd does not respect (e.g. pidfs, nsfs).
> > +      */
>
> The comment says "with custom ->open() and ->permission() ops" but the
> code blocks export if either one is set. The commit message correctly
> says "or" - should the comment be updated to match?
>

Of course.
Will fix for v4.

Thanks,
Amir.

Re: [PATCH v3 0/2] nfsd and special kernel filesystems

[Jeff Layton]

On Wed, 2026-01-28 at 12:16 +0100, Amir Goldstein wrote:
> Christian,
> 
> I noticed that the kernel-doc refactoring queued on vfs-7.0.misc was
> going to conflict with v2 [1], so I rebased over vfs-7.0.misc and split
> it into doc update and nfsd fix patch that could be backported.
> 
> RVBs by Chuck and Jeff were removed due to the slight changes in wording.
> 
> I'd like to acknowledge that Christoph wrote on v2 that:
> "As last time I'd be happy to help write documentation, but even
>  after looking at the methods, their documentations and the commits
>  adding them I do not understand them.  So getting an explanation
>  from Christian would be really helpful to move forward here."
> 
> IMO, further clarifications of the new methods is very much welcome,
> but should not be blocking the merge of this patch set, which at least
> clarifies the WHAT (to use them for) if not the HOW (to use them).
> 
> Thanks,
> Amir.
> 
> Changes since v2:
> - Rebase over vfs-7.0.misc
> - Split to doc/fix patches
> - Remove RVBs
> 
> [1] https://lore.kernel.org/linux-fsdevel/20260122141942.660948-1-amir73il@gmail.com/
> 
> Amir Goldstein (2):
>   exportfs: clarify the documentation of open()/permission() expotrfs
>     ops
>   nfsd: do not allow exporting of special kernel filesystems
> 
>  fs/nfsd/export.c         |  8 +++++---
>  include/linux/exportfs.h | 25 ++++++++++++++++++++++---
>  2 files changed, 27 insertions(+), 6 deletions(-)

Updated version seems reasonable:

Reviewed-by: Jeff Layton <jlayton@kernel.org>