Re: [PATCH v2] NFSv4.2: fix nfs4_listxattr size accounting

On Tue, Jul 14, 2026 at 6:00 PM Scott Mayhew [off-list ref] wrote:

On Tue, 14 Jul 2026, Paul Moore wrote:

quoted

On Fri, Jul 10, 2026 at 6:20 PM Paul Moore [off-list ref] wrote:

quoted

... and scratch that, the offending commit was that one.

   commit 01c2305795a3b6b164df48e72b12022a68fd60c1
   Author: Jeff Layton [off-list ref]
   Date:   Wed Mar 25 10:40:32 2026 -0400

   nfsd: add netlink upcall for the nfsd.fh cache

   Add netlink-based cache upcall support for the expkey (nfsd.fh) cache,
   following the same pattern as the existing svc_export netlink support.

   Add expkey to the cache-type enum, a new expkey attribute-set with
   client, fsidtype, fsid, negative, expiry, and path fields, and the
   expkey-get-reqs / expkey-set-reqs operations to the nfsd YAML spec
   and generated headers.

   Implement nfsd_nl_expkey_get_reqs_dumpit() which snapshots pending
   expkey cache requests and sends each entry's seqno, client name,
   fsidtype, and fsid over netlink.

   Implement nfsd_nl_expkey_set_reqs_doit() which parses expkey cache
   responses from userspace (client, fsidtype, fsid, expiry, and path
   or negative flag) and updates the cache via svc_expkey_lookup() /
   svc_expkey_update().

   Wire up the expkey_notify() callback in svc_expkey_cache_template
   so cache misses trigger NFSD_CMD_CACHE_NOTIFY multicast events with
   NFSD_CACHE_TYPE_EXPKEY.

   Signed-off-by: Jeff Layton [off-list ref]
   Signed-off-by: Chuck Lever [off-list ref]

Playing around with it some this morning on a current Fedora Rawhide
system, I can reproduce the problem with a simple command line:

 %  mount -t nfs localhost:/mnt/test /mnt/nfs_test
 mount.nfs: Connection refused for localhost:/mnt/test on /mnt/nfs_test

... adding an explicit "vers={4,4.1,4.2}" has no effect; versions 2
and 3 are no supported on my kernel builds.  There is nothing obvious
in dmesg.  I've run with SELinux both in permissive mode and disabled
and encountered the same problem.  This doesn't appear to be related
to SELinux, it may simply be that we are the first ones to hit this.

As there was some earlier discussion about this being a wonky
interaction with userspace, here are some of the relevant packages on
my system:

nfs-common-utils-2.9.1-4.rc4.fc45.x86_64
nfs-client-utils-2.9.1-4.rc4.fc45.x86_64
nfsv4-client-utils-2.9.1-4.rc4.fc45.x86_64
nfs-utils-2.9.1-4.rc4.fc45.x86_64

My next step is to try disabling portions of the NFS file handle cache
upcall to see if that is the issue, but it would be nice if the NFS
devs could take a look at this too.  I'm happy to test things out or
answer any questions about my test system.

Pardon the dumb question, but are you positive your NFS server is
running?

I'm slightly embarrassed to admit that your question wasn't as dumb as
one might have thought :)

While my bisection testing used the selinux-testsuite which ensures
the NFS server starts, when I tried to create a simple reproducer to
share with the non-SELinux crowd I neglected to verify that the NFS
server was running, the directory, was exported, etc.  My apologies
for the confusion.  However, the problem was real, even if my
reproducer and error message were junk.

FWIW the netlink upcall requires CAP_NET_ADMIN, which is blocked by the
current selinux-policy on rawhide (and I think it's a dontaudit rule)...

As a quick test I added a quick hack to my policy (allow rule below)
and everything appears to be working again.  Thanks for the pointer!

 allow nfsd_t nfsd_t:capability { net_admin };

-- 
paul-moore.com