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

[Scott Mayhew]

On Tue, 14 Jul 2026, Paul Moore wrote:

> On Fri, Jul 10, 2026 at 6:20 PM Paul Moore <paul at paul-moore.com> wrote:
> >
> > ... and scratch that, the offending commit was that one.
> >
> >    commit 01c2305795a3b6b164df48e72b12022a68fd60c1
> >    Author: Jeff Layton <jlayton at kernel.org>
> >    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 <jlayton at kernel.org>
> >    Signed-off-by: Chuck Lever <chuck.lever at oracle.com>
> 
> 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?  No errors from 'systemctl status nfs-server.service' or
'systemctl status nfs-mountd.service'?  A connection refused error
typically indicates the server isn't running.

What if you add 'no-netlink=1' to the mountd stanza in /etc/nfs.conf and
restart nfs-server.service?

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)...
but you said you've disabled SELinux and reproduced your problem, so I'm
scratching my head.  Plus the symptom I ran into was the mount command
hanging, not a 'connection refused' error.  At any rate I filed
https://github.com/fedora-selinux/selinux-policy/pull/3278 to update the
selinux-policy (no movement on that yet) and the most recent mountd
patch improves the fallback to the old proc interface, but I don't think
it's been added to Fedora yet either.

-Scott

> 
> -- 
> paul-moore.com
>