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@xxxxxxxxxx>
> ---
> 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@xxxxxxxxxx>
