Re: [syzbot] [ext4?] possible deadlock in ext4_map_blocks (2)

[Dave Chinner <david@fromorbit.com>]

On Tue, Dec 03, 2024 at 08:29:32AM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    0e287d31b62b Merge tag 'rtc-6.13' of git://git.kernel.org/..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=179f05e8580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=7903df3280dd39ea
> dashboard link: https://syzkaller.appspot.com/bug?extid=c39928fd177c28b5fa1f
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/555649be4570/disk-0e287d31.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/612b3b44653e/vmlinux-0e287d31.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/9cdc015d8348/bzImage-0e287d31.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+c39928fd177c28b5fa1f@syzkaller.appspotmail.com
> 
> ======================================================
> WARNING: possible circular locking dependency detected
> 6.12.0-syzkaller-11930-g0e287d31b62b #0 Not tainted
> ------------------------------------------------------
> kworker/0:4/5894 is trying to acquire lock:
> ffff888048f4dbb0 (&ei->i_data_sem){++++}-{4:4}, at: ext4_map_blocks+0x3be/0x1990 fs/ext4/inode.c:665
> 
> but task is already holding lock:
> ffff888048f4dec0 (mapping.invalidate_lock){++++}-{4:4}, at: filemap_invalidate_lock_shared include/linux/fs.h:873 [inline]
> ffff888048f4dec0 (mapping.invalidate_lock){++++}-{4:4}, at: page_cache_ra_unbounded+0x143/0x8c0 mm/readahead.c:226
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #6 (mapping.invalidate_lock){++++}-{4:4}:
>        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
>        down_read+0xb1/0xa40 kernel/locking/rwsem.c:1524
>        filemap_invalidate_lock_shared include/linux/fs.h:873 [inline]
>        filemap_fault+0x6e8/0x1950 mm/filemap.c:3332
>        __do_fault+0x137/0x460 mm/memory.c:4907
>        do_read_fault mm/memory.c:5322 [inline]
>        do_fault mm/memory.c:5456 [inline]
>        do_pte_missing mm/memory.c:3979 [inline]
>        handle_pte_fault+0x335a/0x68a0 mm/memory.c:5801
>        __handle_mm_fault mm/memory.c:5944 [inline]
>        handle_mm_fault+0x1106/0x1bb0 mm/memory.c:6112
>        faultin_page mm/gup.c:1187 [inline]
>        __get_user_pages+0x1c82/0x49e0 mm/gup.c:1485
>        populate_vma_page_range+0x264/0x330 mm/gup.c:1923
>        __mm_populate+0x27a/0x460 mm/gup.c:2026
>        mm_populate include/linux/mm.h:3386 [inline]
>        __do_sys_mlockall mm/mlock.c:769 [inline]
>        __se_sys_mlockall+0x3e3/0x4d0 mm/mlock.c:745
>        do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>        do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>        entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> -> #5 (&mm->mmap_lock){++++}-{4:4}:
>        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
>        __might_fault+0xc6/0x120 mm/memory.c:6751
>        _inline_copy_from_user include/linux/uaccess.h:162 [inline]
>        _copy_from_user+0x2a/0xc0 lib/usercopy.c:18
>        copy_from_user include/linux/uaccess.h:212 [inline]
>        __blk_trace_setup kernel/trace/blktrace.c:626 [inline]
>        blk_trace_setup+0xd2/0x1e0 kernel/trace/blktrace.c:648
>        sg_ioctl_common drivers/scsi/sg.c:1114 [inline]
>        sg_ioctl+0xa46/0x2e80 drivers/scsi/sg.c:1156
>        vfs_ioctl fs/ioctl.c:51 [inline]
>        __do_sys_ioctl fs/ioctl.c:906 [inline]
>        __se_sys_ioctl+0xf7/0x170 fs/ioctl.c:892
>        do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>        do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>        entry_SYSCALL_64_after_hwframe+0x77/0x7f

#syz dup: possible deadlock in xfs_vn_update_time


-- 
Dave Chinner
david@fromorbit.com