On Sun, 25 Feb 2024 20:23:56 -0800 Boqun Feng wrote: > On Tue, Feb 13, 2024 at 07:41:50PM +0800, Hillf Danton wrote: > > On Mon, 12 Feb 2024 23:12:22 -0800 > > > HEAD commit: 716f4aaa7b48 Merge tag 'vfs-6.8-rc5.fixes' of git://git.ke.. > > > git tree: upstream > > > console+strace: https://syzkaller.appspot.com/x/log.txt?x=100fd062180000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=1d7c92dd8d5c7a1e > > > dashboard link: https://syzkaller.appspot.com/bug?extid=c2ada45c23d98d646118 > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11fcbd48180000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f6e642180000 > > > > > > ============================================ > > > WARNING: possible recursive locking detected > > > 6.8.0-rc4-syzkaller-00003-g716f4aaa7b48 #0 Not tainted > > > -------------------------------------------- > > > syz-executor354/5071 is trying to acquire lock: > > > ffff888070ee0100 (&ni->ni_lock#3){+.+.}-{3:3}, at: ntfs_set_state+0x1ff/0x6c0 fs/ntfs3/fsntfs.c:947 > > this is a mutex_lock_nested() with a subkey 0. > > > > > > > but task is already holding lock: > > > ffff888070de3c00 (&ni->ni_lock#3){+.+.}-{3:3}, at: ni_trylock fs/ntfs3/ntfs_fs.h:1141 [inline] > > > ffff888070de3c00 (&ni->ni_lock#3){+.+.}-{3:3}, at: ni_write_inode+0x1bc/0x1010 fs/ntfs3/frecord.c:3265 > > These two are try locks. > > > > > > This report looks false positive but raises the question -- what made lockedp > > This is not a false positive by lockdep locking rules, basically it > reported deadlock cases as the follow: > > mutex_trylock(A1); > mutex_trylock(A2); > mutex_lock(A1 /* or A2 */); > > Two things to notice here: 1) these two trylock()s not resulting in > real deadlock cases must be because they are on different lock > instances, 2) deadlock detectors work on lock classes, so although the > mutex_lock() above may be on a different instance (say A3), currently > there is no way for lockdep to tell that. In this case, users need to > use subkeys to tell lockdep mutex_lock() and mutex_trylock() are on > different sets of instannces (i.e. sub classes). Note that subkey == 0 > means the main class. Test non-zero subkey. #syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 716f4aaa7b48 --- x/fs/ntfs3/fsntfs.c +++ y/fs/ntfs3/fsntfs.c @@ -944,7 +944,7 @@ int ntfs_set_state(struct ntfs_sb_info * if (!ni) return -EINVAL; - mutex_lock_nested(&ni->ni_lock, NTFS_INODE_MUTEX_DIRTY); + mutex_lock_nested(&ni->ni_lock, NTFS_INODE_MUTEX_NORMAL); attr = ni_find_attr(ni, NULL, NULL, ATTR_VOL_INFO, NULL, 0, NULL, &mi); if (!attr) { --
