[REGRESSION]: NFS 4.2 reports "Operation Not Supported" on getxattr calls

[REGRESSION]: NFS 4.2 reports "Operation Not Supported" on getxattr calls

[Scott Haiden]

Hello,
Between version v6.16.1 and v6.16.2 on the stable tree, NFS client 
started reporting operation not supported when I issue getxattr calls. I 
simply see:     $ strace -e getxattr getfattr -n user.hash.sha512 
'S01E01 - Kassa.mkv'     getxattr("S01E01 - Kassa.mkv", 
"user.hash.sha512", NULL, 0) = -1 EOPNOTSUPP (Operation not supported)   
   S01E01 - Kassa.mkv: user.hash.sha512: Operation not supported     +++ 
exited with 1 +++
Before this issue cropped up, it simply returned the xattr as expected.

I did a git bisect between those two changes on the stable tree, and
found that the backport of this change 
(https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b01f21cacde9f2878492cf318fee61bf4ccad323 
<https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b01f21cacde9f2878492cf318fee61bf4ccad323>)
onto the stable tree is what caused it to start happening. The 6.12
longterm repo is also affected.
I built mainline 6.17-rc3 and it was still facing the issue as of last 
night, but if I patch a reverse diff of that change on then getxattr 
calls work again.
Please let me know if there's more information I should provide, or if
I'm just doing something wrong.
Thanks,
--Scott

Re: [REGRESSION]: NFS 4.2 reports "Operation Not Supported" on getxattr calls

[Scott Haiden]

That got mangled by my mail client, I'll try (one time) to redo it with 
formatting intact, sorry for the mixup, hopefully this doesn't also get 
mangled:

Hello,

Between version v6.16.1 and v6.16.2 on the stable tree, NFS client 
started reporting operation not supported when I issue getxattr calls. I 
simply see:

     $ strace -e getxattr getfattr -n user.hash.sha512 'S01E01 - Kassa.mkv'
     getxattr("S01E01 - Kassa.mkv", "user.hash.sha512", NULL, 0) = -1 
EOPNOTSUPP (Operation not supported)
     S01E01 - Kassa.mkv: user.hash.sha512: Operation not supported
     +++ exited with 1 +++

Before this issue cropped up, it simply returned the xattr as expected.

I did a git bisect between those two changes on the stable tree, and 
found that the backport of this change 
(https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b01f21cacde9f2878492cf318fee61bf4ccad323 ) 
onto the stable tree is what caused it to start happening. The 6.12 
longterm repo is also affected.

I built mainline 6.17-rc3 and it was still facing the issue as of last 
night, but if I patch a reverse diff of that change on then getxattr 
calls work again.

Please let me know if there's more information I should provide, or if 
I'm just doing something wrong.

Thanks,
--Scott

[PATCH 0/4] More server capability fixes

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

Fix more issues where the client's server capability tracking is
failing.

Trond Myklebust (4):
  NFSv4: Don't clear capabilities that won't be reset
  NFSv4: Clear the NFS_CAP_FS_LOCATIONS flag if it is not set
  NFSv4: Clear NFS_CAP_OPEN_XOR and NFS_CAP_DELEGTIME if not supported
  NFSv4: Clear the NFS_CAP_XATTR flag if not supported by the server

 fs/nfs/client.c   | 2 ++
 fs/nfs/nfs4proc.c | 7 ++++---
 2 files changed, 6 insertions(+), 3 deletions(-)

-- 
2.51.0

[PATCH 1/4] NFSv4: Don't clear capabilities that won't be reset

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

Don't clear the capabilities that are not going to get reset by the call
to _nfs4_server_capabilities().

Reported-by: Scott Haiden <scott.b.haiden@gmail.com>
Fixes: b01f21cacde9 ("NFS: Fix the setting of capabilities when automounting a new filesystem")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
---
 fs/nfs/nfs4proc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 7d2b67e06cc3..5b92fcf45dd7 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -4092,7 +4092,6 @@ int nfs4_server_capabilities(struct nfs_server *server, struct nfs_fh *fhandle)
 	};
 	int err;
 
-	nfs_server_set_init_caps(server);
 	do {
 		err = nfs4_handle_exception(server,
 				_nfs4_server_capabilities(server, fhandle),
-- 
2.51.0

[PATCH 2/4] NFSv4: Clear the NFS_CAP_FS_LOCATIONS flag if it is not set

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

_nfs4_server_capabilities() is expected to clear any flags that are not
supported by the server.

Fixes: 8a59bb93b7e3 ("NFSv4 store server support for fs_location attribute")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.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 5b92fcf45dd7..d0f91d9430f6 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -4013,8 +4013,9 @@ static int _nfs4_server_capabilities(struct nfs_server *server, struct nfs_fh *f
 				     res.attr_bitmask[2];
 		}
 		memcpy(server->attr_bitmask, res.attr_bitmask, sizeof(server->attr_bitmask));
-		server->caps &= ~(NFS_CAP_ACLS | NFS_CAP_HARDLINKS |
-				  NFS_CAP_SYMLINKS| NFS_CAP_SECURITY_LABEL);
+		server->caps &=
+			~(NFS_CAP_ACLS | NFS_CAP_HARDLINKS | NFS_CAP_SYMLINKS |
+			  NFS_CAP_SECURITY_LABEL | NFS_CAP_FS_LOCATIONS);
 		server->fattr_valid = NFS_ATTR_FATTR_V4;
 		if (res.attr_bitmask[0] & FATTR4_WORD0_ACL &&
 				res.acl_bitmask & ACL4_SUPPORT_ALLOW_ACL)
-- 
2.51.0

[PATCH 3/4] NFSv4: Clear NFS_CAP_OPEN_XOR and NFS_CAP_DELEGTIME if not supported

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

_nfs4_server_capabilities() should clear capabilities that are not
supported by the server.

Fixes: d2a00cceb93a ("NFSv4: Detect support for OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
---
 fs/nfs/nfs4proc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index d0f91d9430f6..ce61253efd45 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -4015,7 +4015,8 @@ static int _nfs4_server_capabilities(struct nfs_server *server, struct nfs_fh *f
 		memcpy(server->attr_bitmask, res.attr_bitmask, sizeof(server->attr_bitmask));
 		server->caps &=
 			~(NFS_CAP_ACLS | NFS_CAP_HARDLINKS | NFS_CAP_SYMLINKS |
-			  NFS_CAP_SECURITY_LABEL | NFS_CAP_FS_LOCATIONS);
+			  NFS_CAP_SECURITY_LABEL | NFS_CAP_FS_LOCATIONS |
+			  NFS_CAP_OPEN_XOR | NFS_CAP_DELEGTIME);
 		server->fattr_valid = NFS_ATTR_FATTR_V4;
 		if (res.attr_bitmask[0] & FATTR4_WORD0_ACL &&
 				res.acl_bitmask & ACL4_SUPPORT_ALLOW_ACL)
-- 
2.51.0

[PATCH 4/4] NFSv4: Clear the NFS_CAP_XATTR flag if not supported by the server

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

nfs_server_set_fsinfo() shouldn't assume that NFS_CAP_XATTR is unset
on entry to the function.

Fixes: b78ef845c35d ("NFSv4.2: query the server for extended attribute support")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
---
 fs/nfs/client.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 8fb4a950dd55..4e3dcc157a83 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -888,6 +888,8 @@ static void nfs_server_set_fsinfo(struct nfs_server *server,
 
 	if (fsinfo->xattr_support)
 		server->caps |= NFS_CAP_XATTR;
+	else
+		server->caps &= ~NFS_CAP_XATTR;
 #endif
 }
 
-- 
2.51.0

Re: [PATCH 0/4] More server capability fixes

[Scott Haiden]

Hello,

I just tested 6.16.4 without these changes, which gives the same error, 
and after applying them xattr works properly.

Thanks,
--Scott

Re: [PATCH 0/4] More server capability fixes

[Scott Haiden]

Hello again,

I saw that these patches were marked in patchwork 
(https://patchwork.kernel.org/project/linux-nfs/list/?series=996999&state=*) 
as "handled elsewhere"; could I ask for a link to where they're handled? 
I tried looking at a few other patchsets in the nfs mailing list but I'm 
not that familiar with the NFS source and didn't see any that jumped out 
at me.

I'm hoping to follow the patch so I know when it's safe for me to update 
my kernel again.

Thanks!
--Scott