Re: [PATCH] nfsd: prevent hung task in nfsd_nl_listener_set_doit()

[Jeff Layton]

On Sun, 2026-08-23 at 22:27 +0200, Slawomir Stepien wrote:
> On sie 20, 2026 07:37, Jeff Layton wrote:
> > On Thu, 2026-08-20 at 06:55 +0000, syzbot wrote:
> > > From: Slawomir Stepien <sst@xxxxxxxxx>
> > > 
> > > In nfsd_nl_listener_set_doit(), the kernel iterates over all
> > > NFSD_A_SERVER_SOCK_ADDR attributes provided in a netlink message to
> > > configure NFS server listeners. There is currently no limit on the number
> > > of attributes a user can send.
> > > 
> > > For each attribute, svc_xprt_create_from_sa() is called, which may
> > > synchronously invoke request_module() to load the corresponding transport
> > > module. If a user provides a large number of invalid transport names,
> > > request_module() is called sequentially for each, taking a massive amount
> > > of time. Since this entire process occurs while holding the global
> > > nfsd_mutex, it blocks other tasks attempting to acquire the mutex and
> > > triggers a hung task timeout:
> > > 
> > 
> > My LLM latched onto the same explanation, but the request module
> > upcalls are actually quite quick and have some other gates on them that
> > make this problem hard to hit in practice.
> 
> Oh, OK. Thanks for clearing that up!
> 
> > The real problem is rpcbind registration, which can be quite slow. The
> > fix for that is to make the registration asynchronous, and to not
> > trigger errors on rpcbind registration failure. That's a bigger
> > project, but let us know if you're interested!
> 
> I think I'm not that good to do it correctly and in some reasonable time. I might take a 2nd look at
> this and understand the root cause (also, based on your comments in your series) but I think in the
> end it might be too hard for me.
> 

Fair enough. It's a non-trivial project, and after some discussion with
Chuck, I'm leaning toward moving most of the rpcbind registration into
userland. That'll mean having to rev the netlink protocol, etc.

Right now, I don't have a timeline for working on this, so we're
probably just going to have to suffer with more syzbot reports until
that can come to fruition.
-- 
Jeff Layton <jlayton@xxxxxxxxxx>