Re: [syzbot] [nfs?] INFO: task hung in nfsd_nl_listener_get_doit

[Jeff Layton <jlayton@kernel.org>]

On Mon, 2024-06-17 at 07:51 -0700, Jakub Kicinski wrote:
> On Mon, 17 Jun 2024 06:15:25 -0400 Jeff Layton wrote:
> > We've had number of these reports recently. I think I understand
> > what's
> > happening but I'm not sure how to fix it. The problem manifests as
> > a
> > stuck nfsd_mutex:
> > 
> > nfsd_nl_rpc_status_get_start takes the nfsd_mutex, and it's
> > released in
> > nfsd_nl_rpc_status_get_done. These are the ->start and ->done
> > operations for the rpc_status_get dumpit routine.
> > 
> > I think syzbot is triggering one of the two "goto errout_skb"
> > conditions in netlink_dump (not sure which). In those cases we end
> > up
> > returning from that function without calling ->done, which would
> > lead
> > to the hung mutex like we see here.
> > 
> > Is this a bug in the netlink code, or is the rpc_status_get dumpit
> > routine not using ->start and ->done correctly?
> 
> Dumps are spread over multiple recvmsg() calls, even if we error out
> the next recvmsg() will dump again, until ->done() is called. And
> we'll
> call ->done() if socket is closed without reaching the end.
> 
> But the multi-syscall nature puts us at the mercy of the user meaning
> that holding locks ->start() to ->done() is a bit of a no-no.
> Many of the dumps dump contents of an Xarray, so its easy to remember
> an index and continue dumping from where we left off.

Understood, thanks. I wasn't keyed into the fact that ->start and -
>done weren't always called in the context of the same syscall. In that
case, I think we have no choice but to move the locking into the -
>dumpit routine. I believe Lorenzo is drafting a patch along those
lines.
-- 
Jeff Layton <jlayton@kernel.org>