possible deadlock in ntfs_readpage
9 views
Skip to first unread message
syzbot
Sep 25, 2022, 11:04:43 PM9/25/22
to syzkaller...@googlegroups.com
Hello,
syzbot found the following issue on:
HEAD commit: 4edbf74132a4 Linux 4.14.294
git tree: linux-4.14.y
console output: https://syzkaller.appspot.com/x/log.txt?x=168dfee4880000
kernel config: https://syzkaller.appspot.com/x/.config?x=94d4cf9c4e23980f
dashboard link: https://syzkaller.appspot.com/bug?extid=6071b03fe6fdd40331b7
compiler: gcc version 10.2.1 20210110 (Debian 10.2.1-6)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=147112a8880000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10618c04880000
Downloadable assets:
disk image: https://storage.googleapis.com/b40da19b4827/disk-4edbf741.raw.xz
vmlinux: https://storage.googleapis.com/a36e39677c18/vmlinux-4edbf741.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6071b0...@syzkaller.appspotmail.com
IPVS: ftp: loaded support on port[0] = 21
ntfs: volume version 3.1.
syz-executor110 (7999): drop_caches: 1
syz-executor110 (7999): drop_caches: 1
======================================================
WARNING: possible circular locking dependency detected
4.14.294-syzkaller #0 Not tainted
------------------------------------------------------
kworker/u4:4/2880 is trying to acquire lock:
(&rl->lock){++++}, at: [<ffffffff82100e96>] ntfs_read_block fs/ntfs/aops.c:269 [inline]
(&rl->lock){++++}, at: [<ffffffff82100e96>] ntfs_readpage+0x1396/0x1ad0 fs/ntfs/aops.c:456
but task is already holding lock:
(&ni->mrec_lock){+.+.}, at: [<ffffffff8213be9b>] map_mft_record+0x2b/0xbe0 fs/ntfs/mft.c:166
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&ni->mrec_lock){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0xc4/0x1310 kernel/locking/mutex.c:893
map_mft_record+0x2b/0xbe0 fs/ntfs/mft.c:166
ntfs_map_runlist_nolock+0xab3/0x1630 fs/ntfs/attrib.c:105
ntfs_map_runlist+0x64/0x90 fs/ntfs/attrib.c:306
ntfs_read_block fs/ntfs/aops.c:304 [inline]
ntfs_readpage+0x13e8/0x1ad0 fs/ntfs/aops.c:456
read_pages mm/readahead.c:131 [inline]
__do_page_cache_readahead+0x69b/0x940 mm/readahead.c:199
ra_submit mm/internal.h:66 [inline]
ondemand_readahead.isra.0+0x514/0xb60 mm/readahead.c:486
page_cache_sync_readahead mm/readahead.c:518 [inline]
page_cache_sync_readahead+0xa6/0xf0 mm/readahead.c:503
generic_file_buffered_read mm/filemap.c:2003 [inline]
generic_file_read_iter+0xfbc/0x21c0 mm/filemap.c:2273
call_read_iter include/linux/fs.h:1774 [inline]
new_sync_read fs/read_write.c:401 [inline]
__vfs_read+0x449/0x620 fs/read_write.c:413
integrity_kernel_read+0x11b/0x1b0 security/integrity/iint.c:199
ima_calc_file_hash_tfm security/integrity/ima/ima_crypto.c:381 [inline]
ima_calc_file_shash security/integrity/ima/ima_crypto.c:410 [inline]
ima_calc_file_hash+0x3ee/0x780 security/integrity/ima/ima_crypto.c:467
ima_collect_measurement+0x39d/0x430 security/integrity/ima/ima_api.c:227
process_measurement+0x78b/0xb20 security/integrity/ima/ima_main.c:264
do_last fs/namei.c:3435 [inline]
path_openat+0x10ad/0x2970 fs/namei.c:3571
do_filp_open+0x179/0x3c0 fs/namei.c:3605
do_sys_open+0x296/0x410 fs/open.c:1081
do_syscall_64+0x1d5/0x640 arch/x86/entry/common.c:292
entry_SYSCALL_64_after_hwframe+0x46/0xbb
-> #0 (&rl->lock){++++}:
lock_acquire+0x170/0x3f0 kernel/locking/lockdep.c:3998
down_read+0x36/0x80 kernel/locking/rwsem.c:24
ntfs_read_block fs/ntfs/aops.c:269 [inline]
ntfs_readpage+0x1396/0x1ad0 fs/ntfs/aops.c:456
do_read_cache_page+0x38e/0xc10 mm/filemap.c:2713
read_mapping_page include/linux/pagemap.h:398 [inline]
ntfs_map_page fs/ntfs/aops.h:89 [inline]
ntfs_sync_mft_mirror+0x1f4/0x1560 fs/ntfs/mft.c:490
write_mft_record_nolock+0xece/0x1240 fs/ntfs/mft.c:793
write_mft_record fs/ntfs/mft.h:109 [inline]
__ntfs_write_inode+0x58d/0xcc0 fs/ntfs/inode.c:3077
write_inode fs/fs-writeback.c:1241 [inline]
__writeback_single_inode+0x6a4/0x1010 fs/fs-writeback.c:1439
writeback_sb_inodes+0x48b/0xd30 fs/fs-writeback.c:1645
wb_writeback+0x243/0xb80 fs/fs-writeback.c:1820
wb_do_writeback fs/fs-writeback.c:1952 [inline]
wb_workfn+0x2bd/0xf50 fs/fs-writeback.c:1988
process_one_work+0x793/0x14a0 kernel/workqueue.c:2117
worker_thread+0x5cc/0xff0 kernel/workqueue.c:2251
kthread+0x30d/0x420 kernel/kthread.c:232
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:404
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ni->mrec_lock);
lock(&rl->lock);
lock(&ni->mrec_lock);
lock(&rl->lock);
*** DEADLOCK ***
3 locks held by kworker/u4:4/2880:
#0: ("writeback"){+.+.}, at: [<ffffffff81364eb0>] process_one_work+0x6b0/0x14a0 kernel/workqueue.c:2088
#1: ((&(&wb->dwork)->work)){+.+.}, at: [<ffffffff81364ee6>] process_one_work+0x6e6/0x14a0 kernel/workqueue.c:2092
#2: (&ni->mrec_lock){+.+.}, at: [<ffffffff8213be9b>] map_mft_record+0x2b/0xbe0 fs/ntfs/mft.c:166
stack backtrace:
CPU: 0 PID: 2880 Comm: kworker/u4:4 Not tainted 4.14.294-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
Workqueue: writeback wb_workfn (flush-7:0)
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x1b2/0x281 lib/dump_stack.c:58
print_circular_bug.constprop.0.cold+0x2d7/0x41e kernel/locking/lockdep.c:1258
check_prev_add kernel/locking/lockdep.c:1905 [inline]
check_prevs_add kernel/locking/lockdep.c:2022 [inline]
validate_chain kernel/locking/lockdep.c:2464 [inline]
__lock_acquire+0x2e0e/0x3f20 kernel/locking/lockdep.c:3491
lock_acquire+0x170/0x3f0 kernel/locking/lockdep.c:3998
down_read+0x36/0x80 kernel/locking/rwsem.c:24
ntfs_read_block fs/ntfs/aops.c:269 [inline]
ntfs_readpage+0x1396/0x1ad0 fs/ntfs/aops.c:456
do_read_cache_page+0x38e/0xc10 mm/filemap.c:2713
read_mapping_page include/linux/pagemap.h:398 [inline]
ntfs_map_page fs/ntfs/aops.h:89 [inline]
ntfs_sync_mft_mirror+0x1f4/0x1560 fs/ntfs/mft.c:490
write_mft_record_nolock+0xece/0x1240 fs/ntfs/mft.c:793
write_mft_record fs/ntfs/mft.h:109 [inline]
__ntfs_write_inode+0x58d/0xcc0 fs/ntfs/inode.c:3077
write_inode fs/fs-writeback.c:1241 [inline]
__writeback_single_inode+0x6a4/0x1010 fs/fs-writeback.c:1439
writeback_sb_inodes+0x48b/0xd30 fs/fs-writeback.c:1645
wb_writeback+0x243/0xb80 fs/fs-writeback.c:1820
wb_do_writeback fs/fs-writeback.c:1952 [inline]
wb_workfn+0x2bd/0xf50 fs/fs-writeback.c:1988
process_one_work+0x793/0x14a0 kernel/workqueue.c:2117
worker_thread+0x5cc/0xff0 kernel/workqueue.c:2251
kthread+0x30d/0x420 kernel/kthread.c:232
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:404
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
syzbot found the following issue on:
HEAD commit: 4edbf74132a4 Linux 4.14.294
git tree: linux-4.14.y
console output: https://syzkaller.appspot.com/x/log.txt?x=168dfee4880000
kernel config: https://syzkaller.appspot.com/x/.config?x=94d4cf9c4e23980f
dashboard link: https://syzkaller.appspot.com/bug?extid=6071b03fe6fdd40331b7
compiler: gcc version 10.2.1 20210110 (Debian 10.2.1-6)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=147112a8880000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10618c04880000
Downloadable assets:
disk image: https://storage.googleapis.com/b40da19b4827/disk-4edbf741.raw.xz
vmlinux: https://storage.googleapis.com/a36e39677c18/vmlinux-4edbf741.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6071b0...@syzkaller.appspotmail.com
IPVS: ftp: loaded support on port[0] = 21
ntfs: volume version 3.1.
syz-executor110 (7999): drop_caches: 1
syz-executor110 (7999): drop_caches: 1
======================================================
WARNING: possible circular locking dependency detected
4.14.294-syzkaller #0 Not tainted
------------------------------------------------------
kworker/u4:4/2880 is trying to acquire lock:
(&rl->lock){++++}, at: [<ffffffff82100e96>] ntfs_read_block fs/ntfs/aops.c:269 [inline]
(&rl->lock){++++}, at: [<ffffffff82100e96>] ntfs_readpage+0x1396/0x1ad0 fs/ntfs/aops.c:456
but task is already holding lock:
(&ni->mrec_lock){+.+.}, at: [<ffffffff8213be9b>] map_mft_record+0x2b/0xbe0 fs/ntfs/mft.c:166
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&ni->mrec_lock){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0xc4/0x1310 kernel/locking/mutex.c:893
map_mft_record+0x2b/0xbe0 fs/ntfs/mft.c:166
ntfs_map_runlist_nolock+0xab3/0x1630 fs/ntfs/attrib.c:105
ntfs_map_runlist+0x64/0x90 fs/ntfs/attrib.c:306
ntfs_read_block fs/ntfs/aops.c:304 [inline]
ntfs_readpage+0x13e8/0x1ad0 fs/ntfs/aops.c:456
read_pages mm/readahead.c:131 [inline]
__do_page_cache_readahead+0x69b/0x940 mm/readahead.c:199
ra_submit mm/internal.h:66 [inline]
ondemand_readahead.isra.0+0x514/0xb60 mm/readahead.c:486
page_cache_sync_readahead mm/readahead.c:518 [inline]
page_cache_sync_readahead+0xa6/0xf0 mm/readahead.c:503
generic_file_buffered_read mm/filemap.c:2003 [inline]
generic_file_read_iter+0xfbc/0x21c0 mm/filemap.c:2273
call_read_iter include/linux/fs.h:1774 [inline]
new_sync_read fs/read_write.c:401 [inline]
__vfs_read+0x449/0x620 fs/read_write.c:413
integrity_kernel_read+0x11b/0x1b0 security/integrity/iint.c:199
ima_calc_file_hash_tfm security/integrity/ima/ima_crypto.c:381 [inline]
ima_calc_file_shash security/integrity/ima/ima_crypto.c:410 [inline]
ima_calc_file_hash+0x3ee/0x780 security/integrity/ima/ima_crypto.c:467
ima_collect_measurement+0x39d/0x430 security/integrity/ima/ima_api.c:227
process_measurement+0x78b/0xb20 security/integrity/ima/ima_main.c:264
do_last fs/namei.c:3435 [inline]
path_openat+0x10ad/0x2970 fs/namei.c:3571
do_filp_open+0x179/0x3c0 fs/namei.c:3605
do_sys_open+0x296/0x410 fs/open.c:1081
do_syscall_64+0x1d5/0x640 arch/x86/entry/common.c:292
entry_SYSCALL_64_after_hwframe+0x46/0xbb
-> #0 (&rl->lock){++++}:
lock_acquire+0x170/0x3f0 kernel/locking/lockdep.c:3998
down_read+0x36/0x80 kernel/locking/rwsem.c:24
ntfs_read_block fs/ntfs/aops.c:269 [inline]
ntfs_readpage+0x1396/0x1ad0 fs/ntfs/aops.c:456
do_read_cache_page+0x38e/0xc10 mm/filemap.c:2713
read_mapping_page include/linux/pagemap.h:398 [inline]
ntfs_map_page fs/ntfs/aops.h:89 [inline]
ntfs_sync_mft_mirror+0x1f4/0x1560 fs/ntfs/mft.c:490
write_mft_record_nolock+0xece/0x1240 fs/ntfs/mft.c:793
write_mft_record fs/ntfs/mft.h:109 [inline]
__ntfs_write_inode+0x58d/0xcc0 fs/ntfs/inode.c:3077
write_inode fs/fs-writeback.c:1241 [inline]
__writeback_single_inode+0x6a4/0x1010 fs/fs-writeback.c:1439
writeback_sb_inodes+0x48b/0xd30 fs/fs-writeback.c:1645
wb_writeback+0x243/0xb80 fs/fs-writeback.c:1820
wb_do_writeback fs/fs-writeback.c:1952 [inline]
wb_workfn+0x2bd/0xf50 fs/fs-writeback.c:1988
process_one_work+0x793/0x14a0 kernel/workqueue.c:2117
worker_thread+0x5cc/0xff0 kernel/workqueue.c:2251
kthread+0x30d/0x420 kernel/kthread.c:232
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:404
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ni->mrec_lock);
lock(&rl->lock);
lock(&ni->mrec_lock);
lock(&rl->lock);
*** DEADLOCK ***
3 locks held by kworker/u4:4/2880:
#0: ("writeback"){+.+.}, at: [<ffffffff81364eb0>] process_one_work+0x6b0/0x14a0 kernel/workqueue.c:2088
#1: ((&(&wb->dwork)->work)){+.+.}, at: [<ffffffff81364ee6>] process_one_work+0x6e6/0x14a0 kernel/workqueue.c:2092
#2: (&ni->mrec_lock){+.+.}, at: [<ffffffff8213be9b>] map_mft_record+0x2b/0xbe0 fs/ntfs/mft.c:166
stack backtrace:
CPU: 0 PID: 2880 Comm: kworker/u4:4 Not tainted 4.14.294-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
Workqueue: writeback wb_workfn (flush-7:0)
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x1b2/0x281 lib/dump_stack.c:58
print_circular_bug.constprop.0.cold+0x2d7/0x41e kernel/locking/lockdep.c:1258
check_prev_add kernel/locking/lockdep.c:1905 [inline]
check_prevs_add kernel/locking/lockdep.c:2022 [inline]
validate_chain kernel/locking/lockdep.c:2464 [inline]
__lock_acquire+0x2e0e/0x3f20 kernel/locking/lockdep.c:3491
lock_acquire+0x170/0x3f0 kernel/locking/lockdep.c:3998
down_read+0x36/0x80 kernel/locking/rwsem.c:24
ntfs_read_block fs/ntfs/aops.c:269 [inline]
ntfs_readpage+0x1396/0x1ad0 fs/ntfs/aops.c:456
do_read_cache_page+0x38e/0xc10 mm/filemap.c:2713
read_mapping_page include/linux/pagemap.h:398 [inline]
ntfs_map_page fs/ntfs/aops.h:89 [inline]
ntfs_sync_mft_mirror+0x1f4/0x1560 fs/ntfs/mft.c:490
write_mft_record_nolock+0xece/0x1240 fs/ntfs/mft.c:793
write_mft_record fs/ntfs/mft.h:109 [inline]
__ntfs_write_inode+0x58d/0xcc0 fs/ntfs/inode.c:3077
write_inode fs/fs-writeback.c:1241 [inline]
__writeback_single_inode+0x6a4/0x1010 fs/fs-writeback.c:1439
writeback_sb_inodes+0x48b/0xd30 fs/fs-writeback.c:1645
wb_writeback+0x243/0xb80 fs/fs-writeback.c:1820
wb_do_writeback fs/fs-writeback.c:1952 [inline]
wb_workfn+0x2bd/0xf50 fs/fs-writeback.c:1988
process_one_work+0x793/0x14a0 kernel/workqueue.c:2117
worker_thread+0x5cc/0xff0 kernel/workqueue.c:2251
kthread+0x30d/0x420 kernel/kthread.c:232
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:404
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
syzbot
Sep 26, 2022, 1:24:37 AM9/26/22
to syzkaller...@googlegroups.com
Hello,
syzbot found the following issue on:
HEAD commit: 3f8a27f9e27b Linux 4.19.211
syzbot found the following issue on:
git tree: linux-4.19.y
console output: https://syzkaller.appspot.com/x/log.txt?x=103f552f080000
kernel config: https://syzkaller.appspot.com/x/.config?x=9b9277b418617afe
dashboard link: https://syzkaller.appspot.com/bug?extid=9698d1feae8c8dc58a8f
compiler: gcc version 10.2.1 20210110 (Debian 10.2.1-6)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16cc8540880000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15d74404880000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
IPVS: ftp: loaded support on port[0] = 21
ntfs: volume version 3.1.
syz-executor171 (8076): drop_caches: 1
======================================================
WARNING: possible circular locking dependency detected
4.19.211-syzkaller #0 Not tainted
WARNING: possible circular locking dependency detected
------------------------------------------------------
kworker/u4:2/106 is trying to acquire lock:
00000000fa5c28e8 (&rl->lock){++++}, at: ntfs_read_block fs/ntfs/aops.c:265 [inline]
00000000fa5c28e8 (&rl->lock){++++}, at: ntfs_readpage+0x1909/0x21b0 fs/ntfs/aops.c:452
but task is already holding lock:
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&ni->mrec_lock){+.+.}:
ntfs_map_runlist_nolock+0xbe5/0x17f0 fs/ntfs/attrib.c:105
ntfs_map_runlist+0x77/0xa0 fs/ntfs/attrib.c:306
ntfs_read_block fs/ntfs/aops.c:300 [inline]
ntfs_readpage+0x195b/0x21b0 fs/ntfs/aops.c:452
read_pages.isra.0+0x329/0x5d0 mm/readahead.c:133
__do_page_cache_readahead+0x5c6/0x6c0 mm/readahead.c:211
ra_submit mm/internal.h:66 [inline]
ondemand_readahead.isra.0+0x575/0xd40 mm/readahead.c:493
page_cache_sync_readahead mm/readahead.c:528 [inline]
page_cache_sync_readahead+0x275/0x520 mm/readahead.c:510
generic_file_buffered_read mm/filemap.c:2115 [inline]
generic_file_read_iter+0x1497/0x2b60 mm/filemap.c:2385
call_read_iter include/linux/fs.h:1815 [inline]
new_sync_read fs/read_write.c:406 [inline]
__vfs_read+0x518/0x750 fs/read_write.c:418
integrity_kernel_read+0x147/0x1f0 security/integrity/iint.c:200
ima_calc_file_hash_tfm security/integrity/ima/ima_crypto.c:364 [inline]
ima_calc_file_shash security/integrity/ima/ima_crypto.c:393 [inline]
ima_calc_file_hash+0x4b2/0x8a0 security/integrity/ima/ima_crypto.c:450
ima_collect_measurement+0x4c4/0x570 security/integrity/ima/ima_api.c:231
process_measurement+0xddd/0x1440 security/integrity/ima/ima_main.c:284
ima_file_check+0xb9/0x100 security/integrity/ima/ima_main.c:391
do_last fs/namei.c:3425 [inline]
path_openat+0x7e4/0x2df0 fs/namei.c:3537
do_filp_open+0x18c/0x3f0 fs/namei.c:3567
do_sys_open+0x3b3/0x520 fs/open.c:1085
do_syscall_64+0xf9/0x620 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (&rl->lock){++++}:
ntfs_read_block fs/ntfs/aops.c:265 [inline]
ntfs_readpage+0x1909/0x21b0 fs/ntfs/aops.c:452
do_read_cache_page+0x533/0x1170 mm/filemap.c:2828
read_mapping_page include/linux/pagemap.h:402 [inline]
ntfs_map_page fs/ntfs/aops.h:89 [inline]
ntfs_sync_mft_mirror+0x24f/0x1d00 fs/ntfs/mft.c:494
write_mft_record_nolock+0x13d2/0x16c0 fs/ntfs/mft.c:801
write_mft_record fs/ntfs/mft.h:109 [inline]
__ntfs_write_inode+0x609/0xe10 fs/ntfs/inode.c:3064
write_inode fs/fs-writeback.c:1244 [inline]
__writeback_single_inode+0x733/0x11d0 fs/fs-writeback.c:1442
writeback_sb_inodes+0x537/0xef0 fs/fs-writeback.c:1647
wb_writeback+0x28d/0xcc0 fs/fs-writeback.c:1820
wb_do_writeback fs/fs-writeback.c:1965 [inline]
wb_workfn+0x29b/0x1250 fs/fs-writeback.c:2006
process_one_work+0x864/0x1570 kernel/workqueue.c:2153
worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
kthread+0x33f/0x460 kernel/kthread.c:259
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ni->mrec_lock);
lock(&rl->lock);
lock(&ni->mrec_lock);
lock(&rl->lock);
*** DEADLOCK ***
#0: 000000006769d5a0 ((wq_completion)"writeback"){+.+.}, at: process_one_work+0x767/0x1570 kernel/workqueue.c:2124
#1: 00000000442a2f0b ((work_completion)(&(&wb->dwork)->work)){+.+.}, at: process_one_work+0x79c/0x1570 kernel/workqueue.c:2128
#2: 000000000c7b2067 (&ni->mrec_lock){+.+.}, at: map_mft_record+0x3c/0xc70 fs/ntfs/mft.c:168
stack backtrace:
CPU: 1 PID: 106 Comm: kworker/u4:2 Not tainted 4.19.211-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
Workqueue: writeback wb_workfn (flush-7:0)
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
Workqueue: writeback wb_workfn (flush-7:0)
Call Trace:
dump_stack+0x1fc/0x2ef lib/dump_stack.c:118
print_circular_bug.constprop.0.cold+0x2d7/0x41e kernel/locking/lockdep.c:1222
check_prev_add kernel/locking/lockdep.c:1866 [inline]
check_prevs_add kernel/locking/lockdep.c:1979 [inline]
validate_chain kernel/locking/lockdep.c:2420 [inline]
__lock_acquire+0x30c9/0x3ff0 kernel/locking/lockdep.c:3416
lock_acquire+0x170/0x3c0 kernel/locking/lockdep.c:3908
down_read+0x36/0x80 kernel/locking/rwsem.c:24
ntfs_read_block fs/ntfs/aops.c:265 [inline]
ntfs_readpage+0x1909/0x21b0 fs/ntfs/aops.c:452
do_read_cache_page+0x533/0x1170 mm/filemap.c:2828
read_mapping_page include/linux/pagemap.h:402 [inline]
ntfs_map_page fs/ntfs/aops.h:89 [inline]
ntfs_sync_mft_mirror+0x24f/0x1d00 fs/ntfs/mft.c:494
write_mft_record_nolock+0x13d2/0x16c0 fs/ntfs/mft.c:801
write_mft_record fs/ntfs/mft.h:109 [inline]
__ntfs_write_inode+0x609/0xe10 fs/ntfs/inode.c:3064
write_inode fs/fs-writeback.c:1244 [inline]
__writeback_single_inode+0x733/0x11d0 fs/fs-writeback.c:1442
writeback_sb_inodes+0x537/0xef0 fs/fs-writeback.c:1647
wb_writeback+0x28d/0xcc0 fs/fs-writeback.c:1820
wb_do_writeback fs/fs-writeback.c:1965 [inline]
wb_workfn+0x29b/0x1250 fs/fs-writeback.c:2006
process_one_work+0x864/0x1570 kernel/workqueue.c:2153
worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
Reply all
Reply to author
Forward
0 new messages