Re: [syzbot] Re: [syzbot] [nfs?] [net?] possible deadlock in rpc_close_pipes

[Al Viro <viro@zeniv.linux.org.uk>]

On Wed, Jul 02, 2025 at 06:17:26PM -0700, syzbot wrote:
> For archival purposes, forwarding an incoming command email to
> linux-kernel@vger.kernel.org.
> 
> ***
> 
> Subject: Re: [syzbot] [nfs?] [net?] possible deadlock in rpc_close_pipes
> Author: lizhi.xu@windriver.com
> 
> #syz test
> 
> diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
> index 0bd1df2ebb47..ae5643e0bc43 100644
> --- a/net/sunrpc/rpc_pipe.c
> +++ b/net/sunrpc/rpc_pipe.c
> @@ -693,7 +693,7 @@ void
>  rpc_unlink(struct rpc_pipe *pipe)
>  {
>  	if (pipe->dentry) {
> -		simple_recursive_removal(pipe->dentry, rpc_close_pipes);
> +		locked_recursive_removal(pipe->dentry, rpc_close_pipes);
>  		pipe->dentry = NULL;
>  	}
>  }

Excuse me, but... which caller of rpc_unlink() is holding any directories locked?
IOW, this patch is an LLM-grade nonsense.  If it really *is* chatbot-generated,
that's a lovely demonstration of the reasons why generative AI have no business
sending patches of any kind.

Note that report clearly refers to rpc_close_pipes() as one of the locations
involved in a possible deadlock.  The difference between simple_recursive_removal()
and locked_recursive_removal() is that the latter is to be called when the caller
is already holding ->i_rwsem on the victim's parent.  *IF* that was the case,
the deadlock report would point to that caller vs. simple_recursive_removal().

rpc_close_pipes() is a *callback* passed to simple_recursive_removal(); if it
turned around and called rpc_unlink() we would have a serious problem indeed,
and it's very easy to see that nothing of that sort is happening.

The worst part is, that patch is likely to make lockdep STFU - by failing to
lock the parent.  You really need to reason; "throw random shit at the bot
until the warning goes away" is an actively harmful strategy.

As for the warning, it is a false positive caused by lockdep annotations, as
the original report suggested.  Replace inode_lock(inode) in rpc_close_pipes()
with inode_lock_nested(inode, I_MUTEX_CHILD) and try to reproduce that.

For syzbot maintainers - git blame is useful.  I would really appreciate the
original report...