On Mon, 10 Mar 2025 at 19:21, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Mon, 10 Mar 2025 at 17:50, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Sat, 2025-03-08 at 18:52 -0800, syzbot wrote: > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: e056da87c780 Merge remote-tracking branch 'will/for- > > > next/p.. > > > git tree: > > > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for- > > > kernelci > > > console output: > > > https://syzkaller.appspot.com/x/log.txt?x=14ce9c64580000 > > > kernel config: > > > https://syzkaller.appspot.com/x/.config?x=d6b7e15dc5b5e776 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=019072ad24ab1d948228 > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for > > > Debian) 2.40 > > > userspace arch: arm64 > > > syz repro: > > > https://syzkaller.appspot.com/x/repro.syz?x=111ed7a0580000 > > > C reproducer: > > > https://syzkaller.appspot.com/x/repro.c?x=13b97c64580000 > > > > > > Downloadable assets: > > > disk image: > > > https://storage.googleapis.com/syzbot-assets/3d8b1b7cc4c0/disk-e056da87.raw.xz > > > vmlinux: > > > https://storage.googleapis.com/syzbot-assets/b84c04cff235/vmlinux-e056da87.xz > > > kernel image: > > > https://storage.googleapis.com/syzbot-assets/2ae4d0525881/Image-e056da87.gz.xz > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the > > > commit: > > > Reported-by: syzbot+019072ad24ab1d948228@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > efivarfs: resyncing variable state > > > ============================================ > > > WARNING: possible recursive locking detected > > > 6.14.0-rc4-syzkaller-ge056da87c780 #0 Not tainted > > > -------------------------------------------- > > > syz-executor772/6443 is trying to acquire lock: > > > ffff0000c6826558 (&sb->s_type->i_mutex_key#16){++++}-{4:4}, at: > > > inode_lock include/linux/fs.h:877 [inline] > > > ffff0000c6826558 (&sb->s_type->i_mutex_key#16):4}, at: > > > iterate_dir+0x3b4/0x5f4 fs/readdir.c:101 > > > > > > other info that might help us debug this: > > > Possible unsafe locking scenario: > > > > > > CPU0 > > > ---- > > > lock(&sb->s_type->i_mutex_key#16); > > > lock(&sb->s_type->i_mutex_key#16); > > > > > > *** DEADLOCK *** > > > > I can't figure out how you got here. the shared lock in readdir.c is > > on the directory and the inode_lock in the actor is on the files within > > the directory. The only way to get those to be the same is if the > > actor gets called on the '.' element, which efivarfs_pm_notify is > > supposed to skip with the > > > > file->f_pos = 2; /* skip . and .. */ > > > > line. Emitting the '.' and '..' in positions 0 and 1 is hard coded > > into libfs.c:dcache_readdir() unless you're also applying a patch that > > alters that behaviour? > > > > The repro log also has > > program crashed: BUG: unable to handle kernel paging request in > efivarfs_pm_notify > > preceding the other log output regarding the locks, so the deadlock > might be a symptom of another problem. And one of the other logs has [ 47.650966][ T6617] syz.2.9/6617 is trying to acquire lock: [ 47.652339][ T6617] ffff0000d69f6558 (&sb->s_type->i_mutex_key#25){++++}-{4:4}, at: efivarfs_actor+0x1b8/0x2b8 [ 47.654943][ T6617] [ 47.654943][ T6617] but task is already holding lock: [ 47.656931][ T6617] ffff0000f5b84558 (&sb->s_type->i_mutex_key#25){++++}-{4:4}, at: iterate_dir+0x3b4/0x5f4 where the locks have the same name but the address is different. So there is something dodgy going on here, and I'm inclined to just ignore it.
