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@xxxxxxxxxx>
