linux-kernel - Re: [syzbot] Re: [syzbot] [nfs?] [net?] possible deadlock in rpc_close

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250703022704.GI1880847@ZenIV>
Date: Thu, 3 Jul 2025 03:27:04 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: syzbot <syzbot+169de184e9defe7fe709@...kaller.appspotmail.com>
Cc: linux-kernel@...r.kernel.org, lizhi.xu@...driver.com
Subject: Re: [syzbot] Re: [syzbot] [nfs?] [net?] possible deadlock in
 rpc_close_pipes

On Thu, Jul 03, 2025 at 02:50:33AM +0100, Al Viro wrote:

> 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.

Nope...  I_MUTEX_CHILD is outside of I_MUTEX_NORMAL, not the other way round.

OK, so the right annotations would be I_MUTEX_CHILD in __simple_recursive_removal(),
with I_MUTEX_NORMAL in rpc_close_pipes() and, for callers of locked_recursive_removal(),
I_MUTEX_PARENT.

The nesting order is PARENT, then CHILD, then NORMAL.  Sure, we could leave
annotations in simple_recursive_removal() as-is and switch rpc_close_pipes() to
e.g. I_MUTEX_XATTR, but that's too brittle for words.

The ordering is "ancestors before descendents", and it is satisfied here; the
question is how to map it to lockdep classes ;-/