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

[James Bottomley]

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?

Regards,

James