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.
