Re: [syzbot] [efi?] [fs?] possible deadlock in efivarfs_actor

[Ard Biesheuvel]

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.