On Thu, 26 Jun 2025 06:59:14 +0930 Qu Wenruo wrote:
=E5=9C=A8 2025/6/25 22:10, Hillf Danton =E5=86=99=E9=81=93:Fine, feel free to show us the Tested-by syzbot gave you.
On Wed, 25 Jun 2025 20:19:06 +0930 Qu Wenruo wrote:=3D93:
=3DE5=3D9C=3DA8 2025/6/25 09:26, Hillf Danton =3DE5=3D86=3D99=3DE9=3D81=
86=3D3D99=3D3DE9=3DOn Wed, 25 Jun 2025 06:00:09 +0930 Qu Wenruo wrote:
=3D3DE5=3D3D9C=3D3DA8 2025/6/25 00:00, Edward Adam Davis =3D3DE5=3D3D=
k=3D3D81=3D3D93:
Remove the lock uuid_mutex outside of sget_fc() to avoid the deadloc=
p=3D20reported by [1].
=3D3D20
[1]
-> #1 (&type->s_umount_key#41/1){+.+.}-{4:4}:
lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1693
alloc_super+0x204/0x970 fs/super.c:345
Given kzalloc [3], the syzbot report is false positive (a known lockde=
t.=3Dissue) as nobody else should acquire s->s_umount lock.
=3D20
[3] https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-nex=
0git/tree/fs/super.c?id=3D3D7aacdf6feed1#n319
Not a false alert either.
sget_fc() can return an existing super block, we can race between a=3D2=
mount and an unmount on the same super block.Can v5 survive the syzbot test?
In that case it's going to cause problem.
This is already fixed in the v4 (and later v5) patchset:
https://lore.kernel.org/linux-btrfs/cover.1750724841.git.wqu@xxxxxxxx/
Yes, I enabled lockdep during v5 tests.