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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 11, 2024 at 11:32:23AM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    b5f217084ab3 Merge tag 'bpf-fixes' of git://git.kernel.org..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=164170f8580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=1362a5aee630ff34
> dashboard link: https://syzkaller.appspot.com/bug?extid=cbcad0f3b7646f8653ee
> 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/4000132d9d47/disk-b5f21708.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/85cadac2b6fb/vmlinux-b5f21708.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/0321667f4cf4/bzImage-b5f21708.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+cbcad0f3b7646f8653ee@xxxxxxxxxxxxxxxxxxxxxxxxx
> 
> loop4: detected capacity change from 0 to 2048
> EXT4-fs (loop4): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
> ======================================================
> WARNING: yossible circular locking dependency detected
> 6.13.0-rc1-syzkaller-00316-gb5f217084ab3 #0 Not tainted
> ------------------------------------------------------
> syz.4.1456/13188 is trying to acquire lock:
> ffff888040d89658 (&ei->i_data_sem){++++}-{4:4}, at: ext4_da_map_blocks fs/ext4/inode.c:1799 [inline]
> ffff888040d89658 (&ei->i_data_sem){++++}-{4:4}, at: ext4_da_get_block_prep+0x428/0x1900 fs/ext4/inode.c:1873
> 
> but task is already holding lock:
> ffff888040d89498 (&ei->xattr_sem){++++}-{4:4}, at: ext4_da_convert_inline_data_to_extent fs/ext4/inline.c:846 [inline]
> ffff888040d89498 (&ei->xattr_sem){++++}-{4:4}, at: ext4_da_write_inline_data_begin+0x2d3/0x1090 fs/ext4/inline.c:921
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #7 (&ei->xattr_sem){++++}-{4:4}:
>        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
>        down_read+0xb1/0xa40 kernel/locking/rwsem.c:1524
>        ext4_readpage_inline+0x36/0x6b0 fs/ext4/inline.c:518
>        ext4_read_folio+0x174/0x340 fs/ext4/inode.c:3185
>        filemap_read_folio+0x14d/0x630 mm/filemap.c:2366
>        filemap_create_folio mm/filemap.c:2497 [inline]
>        filemap_get_pages+0x100a/0x2540 mm/filemap.c:2555
>        filemap_read+0x45c/0xf50 mm/filemap.c:2646
>        __kernel_read+0x515/0x9d0 fs/read_write.c:523
>        integrity_kernel_read+0xb0/0x100 security/integrity/iint.c:28
>        ima_calc_file_hash_tfm security/integrity/ima/ima_crypto.c:480 [inline]
>        ima_calc_file_shash security/integrity/ima/ima_crypto.c:511 [inline]
>        ima_calc_file_hash+0xae6/0x1b30 security/integrity/ima/ima_crypto.c:568
>        ima_collect_measurement+0x520/0xb10 security/integrity/ima/ima_api.c:293
>        process_measurement+0x1351/0x1fb0 security/integrity/ima/ima_main.c:372
>        ima_file_check+0xd9/0x120 security/integrity/ima/ima_main.c:572
>        security_file_post_open+0xb9/0x280 security/security.c:3121
>        do_open fs/namei.c:3830 [inline]
>        path_openat+0x2ccd/0x3590 fs/namei.c:3987
>        do_filp_open+0x27f/0x4e0 fs/namei.c:4014
>        do_sys_openat2+0x13e/0x1d0 fs/open.c:1402
>        do_sys_open fs/open.c:1417 [inline]
>        __do_sys_openat fs/open.c:1433 [inline]
>        __se_sys_openat fs/open.c:1428 [inline]
>        __x64_sys_openat+0x247/0x2a0 fs/open.c:1428
>        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
> 
> -> #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]
>        page_cache_ra_unbounded+0x143/0x8c0 mm/readahead.c:226
>        do_async_mmap_readahead mm/filemap.c:3231 [inline]
>        filemap_fault+0x82a/0x1950 mm/filemap.c:3330
>        __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
>        __get_user_pages_locked mm/gup.c:1751 [inline]
>        get_dump_page+0x155/0x2f0 mm/gup.c:2269
>        dump_user_range+0x14d/0x970 fs/coredump.c:943
>        elf_core_dump+0x3e9f/0x4790 fs/binfmt_elf.c:2129
>        do_coredump+0x229d/0x3100 fs/coredump.c:758
>        get_signal+0x140b/0x1750 kernel/signal.c:3002
>        arch_do_signal_or_restart+0x96/0x860 arch/x86/kernel/signal.c:337
>        exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
>        exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
>        irqentry_exit_to_user_mode+0x7e/0x250 kernel/entry/common.c:231
>        exc_page_fault+0x590/0x8b0 arch/x86/mm/fault.c:1542
>        asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
> 
> -> #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_ioctl+0x1ad/0x9a0 kernel/trace/blktrace.c:740
>        blkdev_ioctl+0x40c/0x6a0 block/ioctl.c:682
>        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@xxxxxxxxxxxxx




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux