Message-ID: <d078e70f-33f0-4f9d-8489-c39815d0641b@oracle.com>
Date: Mon, 19 Jan 2026 11:51:47 -0500
From: Chuck Lever <chuck.lever@...cle.com>
To: Jeff Layton <jlayton@...nel.org>, Christian Brauner <brauner@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>, NeilBrown <neil@...wn.name>,
        Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo <Dai.Ngo@...cle.com>,
        Tom Talpey <tom@...pey.com>, Amir Goldstein <amir73il@...il.com>,
        Hugh Dickins <hughd@...gle.com>,
        Baolin Wang
 <baolin.wang@...ux.alibaba.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Theodore Ts'o <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>, Jan Kara <jack@...e.com>,
        Gao Xiang <xiang@...nel.org>, Chao Yu <chao@...nel.org>,
        Yue Hu <zbestahu@...il.com>, Jeffle Xu <jefflexu@...ux.alibaba.com>,
        Sandeep Dhavale
 <dhavale@...gle.com>,
        Hongbo Li <lihongbo22@...wei.com>, Chunhai Guo <guochunhai@...o.com>,
        Carlos Maiolino <cem@...nel.org>, Ilya Dryomov <idryomov@...il.com>,
        Alex Markuze <amarkuze@...hat.com>,
        Viacheslav Dubeyko <slava@...eyko.com>, Chris Mason <clm@...com>,
        David Sterba <dsterba@...e.com>,
        Luis de Bethencourt <luisbg@...nel.org>,
        Salah Triki <salah.triki@...il.com>,
        Phillip Lougher <phillip@...ashfs.org.uk>,
        Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.org>,
        Ronnie Sahlberg <ronniesahlberg@...il.com>,
        Shyam Prasad N <sprasad@...rosoft.com>,
        Bharath SM
 <bharathsm@...rosoft.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        Mike Marshall <hubcap@...ibond.com>,
        Martin Brandenburg
 <martin@...ibond.com>,
        Mark Fasheh <mark@...heh.com>, Joel Becker <jlbec@...lplan.org>,
        Joseph Qi <joseph.qi@...ux.alibaba.com>,
        Konstantin Komarov <almaz.alexandrovich@...agon-software.com>,
        Ryusuke Konishi <konishi.ryusuke@...il.com>,
        Trond Myklebust <trondmy@...nel.org>, Anna Schumaker <anna@...nel.org>,
        Dave Kleikamp <shaggy@...nel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Richard Weinberger <richard@....at>, Jan Kara <jack@...e.cz>,
        Andreas Gruenbacher <agruenba@...hat.com>,
        OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
        Jaegeuk Kim <jaegeuk@...nel.org>, Jonathan Corbet <corbet@....net>
Cc: David Laight <david.laight.linux@...il.com>,
        Dave Chinner <david@...morbit.com>,
        Christoph Hellwig <hch@...radead.org>, linux-nfs@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org, linux-ext4@...r.kernel.org,
        linux-erofs@...ts.ozlabs.org, linux-xfs@...r.kernel.org,
        ceph-devel@...r.kernel.org, linux-btrfs@...r.kernel.org,
        linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
        linux-unionfs@...r.kernel.org, devel@...ts.orangefs.org,
        ocfs2-devel@...ts.linux.dev, ntfs3@...ts.linux.dev,
        linux-nilfs@...r.kernel.org, jfs-discussion@...ts.sourceforge.net,
        linux-mtd@...ts.infradead.org, gfs2@...ts.linux.dev,
        linux-f2fs-devel@...ts.sourceforge.net, linux-doc@...r.kernel.org
Subject: Re: [PATCH v2 30/31] nfsd: only allow filesystems that set
 EXPORT_OP_STABLE_HANDLES

On 1/19/26 11:26 AM, Jeff Layton 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 stable across
> reboots.
> 
> In check_export(), check whether EXPORT_OP_STABLE_HANDLES is set
> and return -EINVAL if it isn't.
> 
> Signed-off-by: Jeff Layton <jlayton@...nel.org>
> ---
>  fs/nfsd/export.c | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
> index 2a1499f2ad196a6033787260881e451146283bdc..bc703cf58bfa210c7c57d49f22f15bc10d7cfc91 100644
> --- a/fs/nfsd/export.c
> +++ b/fs/nfsd/export.c
> @@ -422,13 +422,15 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
>  	if (*flags & NFSEXP_V4ROOT)
>  		*flags |= NFSEXP_READONLY;
>  
> -	/* There are two requirements on a filesystem to be exportable.
> -	 * 1:  We must be able to identify the filesystem from a number.
> +	/* There are four requirements on a filesystem to be exportable:
> +	 * 1: We must be able to identify the filesystem from a number.
>  	 *       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.
> +	 * 2: We must be able to find an inode from a filehandle.
>  	 *       This means that s_export_op must be set.
> -	 * 3: We must not currently be on an idmapped mount.
> +	 * 3: It must provide stable filehandles.
> +	 *       This means that EXPORT_OP_STABLE_HANDLES is set
> +	 * 4: We must not currently be on an idmapped mount.
>  	 */

Let's avoid the royal "we" here... It seems to mean something
different in each of these rules. How about:

1. The filehandle must identify a filesystem by number

2. The filehandle must uniquely identify an inode

3. The exported filesystem must provide stable filehandles

4. The requested file must not reside on an idmapped mount


>  	if (!(inode->i_sb->s_type->fs_flags & FS_REQUIRES_DEV) &&
>  	    !(*flags & NFSEXP_FSID) &&
> @@ -442,6 +444,11 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
>  		return -EINVAL;
>  	}
>  
> +	if (!(inode->i_sb->s_export_op->flags & EXPORT_OP_STABLE_HANDLES)) {
> +		dprintk("%s: fs does not provide stable filehandles!\n", __func__);
> +		return -EINVAL;
> +	}
> +
>  	if (is_idmapped_mnt(path->mnt)) {
>  		dprintk("exp_export: export of idmapped mounts not yet supported.\n");
>  		return -EINVAL;
> 

Reviewed-by: Chuck Lever <chuck.lever@...cle.com>


-- 
Chuck Lever

Powered by blists - more mailing lists