[PATCH] NFSv4: Don't check for OPEN feature support in v4.1

[PATCH] NFSv4: Don't check for OPEN feature support in v4.1

[Scott Mayhew]

fattr4_open_arguments is a v4.2 recommended attribute, so we shouldn't
be sending it to v4.1 servers.

Fixes: cb78f9b7d0c0 ("nfs: fix the fetch of FATTR4_OPEN_ARGUMENTS")
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
---
 fs/nfs/nfs4proc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 970f28dbf253..2eb2d750a5f1 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -3967,8 +3967,9 @@ static int _nfs4_server_capabilities(struct nfs_server *server, struct nfs_fh *f
 		     FATTR4_WORD0_CASE_INSENSITIVE |
 		     FATTR4_WORD0_CASE_PRESERVING;
 	if (minorversion)
-		bitmask[2] = FATTR4_WORD2_SUPPATTR_EXCLCREAT |
-			     FATTR4_WORD2_OPEN_ARGUMENTS;
+		bitmask[2] = FATTR4_WORD2_SUPPATTR_EXCLCREAT;
+	if (minorversion > 1)
+		bitmask[2] |= FATTR4_WORD2_OPEN_ARGUMENTS;
 
 	status = nfs4_call_sync(server->client, server, &msg, &args.seq_args, &res.seq_res, 0);
 	if (status == 0) {
-- 
2.48.1

Re: [PATCH] NFSv4: Don't check for OPEN feature support in v4.1

[Jeff Layton]

On Wed, 2025-04-30 at 07:12 -0400, Scott Mayhew wrote:
> fattr4_open_arguments is a v4.2 recommended attribute, so we shouldn't
> be sending it to v4.1 servers.
> 
> Fixes: cb78f9b7d0c0 ("nfs: fix the fetch of FATTR4_OPEN_ARGUMENTS")
> Signed-off-by: Scott Mayhew <smayhew@redhat.com>
> ---
>  fs/nfs/nfs4proc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 970f28dbf253..2eb2d750a5f1 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -3967,8 +3967,9 @@ static int _nfs4_server_capabilities(struct nfs_server *server, struct nfs_fh *f
>  		     FATTR4_WORD0_CASE_INSENSITIVE |
>  		     FATTR4_WORD0_CASE_PRESERVING;
>  	if (minorversion)
> -		bitmask[2] = FATTR4_WORD2_SUPPATTR_EXCLCREAT |
> -			     FATTR4_WORD2_OPEN_ARGUMENTS;
> +		bitmask[2] = FATTR4_WORD2_SUPPATTR_EXCLCREAT;
> +	if (minorversion > 1)
> +		bitmask[2] |= FATTR4_WORD2_OPEN_ARGUMENTS;
>  
>  	status = nfs4_call_sync(server->client, server, &msg, &args.seq_args, &res.seq_res, 0);
>  	if (status == 0) {

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

Re: [PATCH] NFSv4: Don't check for OPEN feature support in v4.1

[Benjamin Coddington]

On 30 Apr 2025, at 7:12, Scott Mayhew wrote:

> fattr4_open_arguments is a v4.2 recommended attribute, so we shouldn't
> be sending it to v4.1 servers.
>
> Fixes: cb78f9b7d0c0 ("nfs: fix the fetch of FATTR4_OPEN_ARGUMENTS")
> Signed-off-by: Scott Mayhew <smayhew@redhat.com>

Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Cc: stable@vger.kernel.org # 6.11+


It would be lovely to have this fixed in v6.15.

Ben

Re: [PATCH] NFSv4: Don't check for OPEN feature support in v4.1

[Jeff Layton]

On Wed, 2025-04-30 at 07:12 -0400, Scott Mayhew wrote:
> fattr4_open_arguments is a v4.2 recommended attribute, so we shouldn't
> be sending it to v4.1 servers.
> 
> Fixes: cb78f9b7d0c0 ("nfs: fix the fetch of FATTR4_OPEN_ARGUMENTS")
> Signed-off-by: Scott Mayhew <smayhew@redhat.com>
> ---
>  fs/nfs/nfs4proc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 970f28dbf253..2eb2d750a5f1 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -3967,8 +3967,9 @@ static int _nfs4_server_capabilities(struct nfs_server *server, struct nfs_fh *f
>  		     FATTR4_WORD0_CASE_INSENSITIVE |
>  		     FATTR4_WORD0_CASE_PRESERVING;
>  	if (minorversion)
> -		bitmask[2] = FATTR4_WORD2_SUPPATTR_EXCLCREAT |
> -			     FATTR4_WORD2_OPEN_ARGUMENTS;
> +		bitmask[2] = FATTR4_WORD2_SUPPATTR_EXCLCREAT;
> +	if (minorversion > 1)
> +		bitmask[2] |= FATTR4_WORD2_OPEN_ARGUMENTS;
>  
>  	status = nfs4_call_sync(server->client, server, &msg, &args.seq_args, &res.seq_res, 0);
>  	if (status == 0) {

I just want to point out that this _shouldn't_ be a problem with a
properly functioning server. The server should just not return the
attribute in the reply rather than returning a hard error or failing
when it doesn't recognize the attribute.

If requesting this was causing a problem, then it's probably indicative
of a server bug.
-- 
Jeff Layton <jlayton@kernel.org>