[syzbot] INFO: task can't die in blkdev_common_ioctl

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: f81e94e91878 Add linux-next specific files for 20211125
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=168d578db00000
kernel config: https://syzkaller.appspot.com/x/.config?x=be9183de0824e4d7
dashboard link: https://syzkaller.appspot.com/bug?extid=4f1a237abaf14719db49
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4f1a23...@syzkaller.appspotmail.com

INFO: task syz-executor.1:32540 can't die for more than 143 seconds.
task:syz-executor.1 state:D stack:27192 pid:32540 ppid: 14712 flags:0x00004004
Call Trace:
<TASK>
context_switch kernel/sched/core.c:4983 [inline]
__schedule+0xab2/0x4d90 kernel/sched/core.c:6293
schedule+0xd2/0x260 kernel/sched/core.c:6366
rwsem_down_write_slowpath+0x761/0x1130 kernel/locking/rwsem.c:1117
__down_write_common kernel/locking/rwsem.c:1272 [inline]
__down_write_common kernel/locking/rwsem.c:1269 [inline]
__down_write kernel/locking/rwsem.c:1281 [inline]
down_write+0x135/0x150 kernel/locking/rwsem.c:1528
filemap_invalidate_lock include/linux/fs.h:828 [inline]
blk_ioctl_zeroout block/ioctl.c:155 [inline]
blkdev_common_ioctl+0xcae/0x1790 block/ioctl.c:459
blkdev_ioctl+0x2ca/0x800 block/ioctl.c:582
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f040b032ae9
RSP: 002b:00007f0409fa8188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f040b145f60 RCX: 00007f040b032ae9
RDX: 0000000020000080 RSI: 000000000000127f RDI: 0000000000000004
RBP: 00007f040b08cff7 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffe1ed4671f R14: 00007f0409fa8300 R15: 0000000000022000
</TASK>
INFO: task syz-executor.1:32540 blocked for more than 144 seconds.
Not tainted 5.16.0-rc2-next-20211125-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.1 state:D stack:27192 pid:32540 ppid: 14712 flags:0x00004004
Call Trace:
<TASK>
context_switch kernel/sched/core.c:4983 [inline]
__schedule+0xab2/0x4d90 kernel/sched/core.c:6293
schedule+0xd2/0x260 kernel/sched/core.c:6366
rwsem_down_write_slowpath+0x761/0x1130 kernel/locking/rwsem.c:1117
__down_write_common kernel/locking/rwsem.c:1272 [inline]
__down_write_common kernel/locking/rwsem.c:1269 [inline]
__down_write kernel/locking/rwsem.c:1281 [inline]
down_write+0x135/0x150 kernel/locking/rwsem.c:1528
filemap_invalidate_lock include/linux/fs.h:828 [inline]
blk_ioctl_zeroout block/ioctl.c:155 [inline]
blkdev_common_ioctl+0xcae/0x1790 block/ioctl.c:459
blkdev_ioctl+0x2ca/0x800 block/ioctl.c:582
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f040b032ae9
RSP: 002b:00007f0409fa8188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f040b145f60 RCX: 00007f040b032ae9
RDX: 0000000020000080 RSI: 000000000000127f RDI: 0000000000000004
RBP: 00007f040b08cff7 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffe1ed4671f R14: 00007f0409fa8300 R15: 0000000000022000
</TASK>
INFO: task syz-executor.3:32562 can't die for more than 144 seconds.
task:syz-executor.3 state:R running task stack:24976 pid:32562 ppid: 12533 flags:0x00004006
Call Trace:
<TASK>
context_switch kernel/sched/core.c:4983 [inline]
__schedule+0xab2/0x4d90 kernel/sched/core.c:6293
</TASK>
INFO: task syz-executor.3:32564 can't die for more than 145 seconds.
task:syz-executor.3 state:R running task stack:25248 pid:32564 ppid: 12533 flags:0x00004006
Call Trace:
<TASK>
context_switch kernel/sched/core.c:4983 [inline]
__schedule+0xab2/0x4d90 kernel/sched/core.c:6293
</TASK>
INFO: task syz-executor.2:32582 can't die for more than 146 seconds.
task:syz-executor.2 state:D stack:27192 pid:32582 ppid: 14575 flags:0x00004004
Call Trace:
<TASK>
context_switch kernel/sched/core.c:4983 [inline]
__schedule+0xab2/0x4d90 kernel/sched/core.c:6293
schedule+0xd2/0x260 kernel/sched/core.c:6366
rwsem_down_write_slowpath+0x761/0x1130 kernel/locking/rwsem.c:1117
__down_write_common kernel/locking/rwsem.c:1272 [inline]
__down_write_common kernel/locking/rwsem.c:1269 [inline]
__down_write kernel/locking/rwsem.c:1281 [inline]
down_write+0x135/0x150 kernel/locking/rwsem.c:1528
filemap_invalidate_lock include/linux/fs.h:828 [inline]
blk_ioctl_zeroout block/ioctl.c:155 [inline]
blkdev_common_ioctl+0xcae/0x1790 block/ioctl.c:459
blkdev_ioctl+0x2ca/0x800 block/ioctl.c:582
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f9254295ae9
RSP: 002b:00007f925320b188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f92543a8f60 RCX: 00007f9254295ae9
RDX: 0000000020000080 RSI: 000000000000127f RDI: 0000000000000004
RBP: 00007f92542efff7 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffe50e9b58f R14: 00007f925320b300 R15: 0000000000022000
</TASK>
INFO: task syz-executor.2:32582 blocked for more than 147 seconds.
Not tainted 5.16.0-rc2-next-20211125-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.2 state:D stack:27192 pid:32582 ppid: 14575 flags:0x00004004
Call Trace:
<TASK>
context_switch kernel/sched/core.c:4983 [inline]
__schedule+0xab2/0x4d90 kernel/sched/core.c:6293
schedule+0xd2/0x260 kernel/sched/core.c:6366
rwsem_down_write_slowpath+0x761/0x1130 kernel/locking/rwsem.c:1117
__down_write_common kernel/locking/rwsem.c:1272 [inline]
__down_write_common kernel/locking/rwsem.c:1269 [inline]
__down_write kernel/locking/rwsem.c:1281 [inline]
down_write+0x135/0x150 kernel/locking/rwsem.c:1528
filemap_invalidate_lock include/linux/fs.h:828 [inline]
blk_ioctl_zeroout block/ioctl.c:155 [inline]
blkdev_common_ioctl+0xcae/0x1790 block/ioctl.c:459
blkdev_ioctl+0x2ca/0x800 block/ioctl.c:582
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f9254295ae9
RSP: 002b:00007f925320b188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f92543a8f60 RCX: 00007f9254295ae9
RDX: 0000000020000080 RSI: 000000000000127f RDI: 0000000000000004
RBP: 00007f92542efff7 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffe50e9b58f R14: 00007f925320b300 R15: 0000000000022000
</TASK>
INFO: task syz-executor.5:32584 can't die for more than 147 seconds.
task:syz-executor.5 state:D stack:28496 pid:32584 ppid: 10070 flags:0x00000004
Call Trace:
<TASK>
context_switch kernel/sched/core.c:4983 [inline]
__schedule+0xab2/0x4d90 kernel/sched/core.c:6293
schedule+0xd2/0x260 kernel/sched/core.c:6366
rwsem_down_write_slowpath+0x761/0x1130 kernel/locking/rwsem.c:1117
__down_write_common kernel/locking/rwsem.c:1272 [inline]
__down_write_common kernel/locking/rwsem.c:1269 [inline]
__down_write kernel/locking/rwsem.c:1281 [inline]
down_write+0x135/0x150 kernel/locking/rwsem.c:1528
filemap_invalidate_lock include/linux/fs.h:828 [inline]
blk_ioctl_zeroout block/ioctl.c:155 [inline]
blkdev_common_ioctl+0xcae/0x1790 block/ioctl.c:459
blkdev_ioctl+0x2ca/0x800 block/ioctl.c:582
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fb7df573ae9
RSP: 002b:00007fb7de4e9188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fb7df686f60 RCX: 00007fb7df573ae9
RDX: 0000000020000080 RSI: 000000000000127f RDI: 0000000000000004
RBP: 00007fb7df5cdff7 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffd0303ab7f R14: 00007fb7de4e9300 R15: 0000000000022000
</TASK>
INFO: task syz-executor.5:32584 blocked for more than 148 seconds.
Not tainted 5.16.0-rc2-next-20211125-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.5 state:D stack:28496 pid:32584 ppid: 10070 flags:0x00000004
Call Trace:
<TASK>
context_switch kernel/sched/core.c:4983 [inline]
__schedule+0xab2/0x4d90 kernel/sched/core.c:6293
schedule+0xd2/0x260 kernel/sched/core.c:6366
rwsem_down_write_slowpath+0x761/0x1130 kernel/locking/rwsem.c:1117
__down_write_common kernel/locking/rwsem.c:1272 [inline]
__down_write_common kernel/locking/rwsem.c:1269 [inline]
__down_write kernel/locking/rwsem.c:1281 [inline]
down_write+0x135/0x150 kernel/locking/rwsem.c:1528
filemap_invalidate_lock include/linux/fs.h:828 [inline]
blk_ioctl_zeroout block/ioctl.c:155 [inline]
blkdev_common_ioctl+0xcae/0x1790 block/ioctl.c:459
blkdev_ioctl+0x2ca/0x800 block/ioctl.c:582
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fb7df573ae9
RSP: 002b:00007fb7de4e9188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fb7df686f60 RCX: 00007fb7df573ae9
RDX: 0000000020000080 RSI: 000000000000127f RDI: 0000000000000004
RBP: 00007fb7df5cdff7 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffd0303ab7f R14: 00007fb7de4e9300 R15: 0000000000022000
</TASK>

Showing all locks held in the system:
1 lock held by khungtaskd/27:
#0: ffffffff8bb83220 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6458
2 locks held by kswapd0/98:
1 lock held by kswapd1/99:
2 locks held by kworker/u4:4/302:
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline]
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:635 [inline]
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:662 [inline]
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2270
#1: ffff8880b9d279c8 (&per_cpu_ptr(group->pcpu, cpu)->seq){-.-.}-{0:0}, at: psi_task_switch+0x3e7/0x4e0 kernel/sched/psi.c:891
1 lock held by in:imklog/6219:
#0: ffff888077cd0d70 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990
2 locks held by agetty/6483:
#0: ffff888078937098 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x22/0x80 drivers/tty/tty_ldisc.c:252
#1: ffffc90001a5c2e8 (&ldata->atomic_read_lock){+.+.}-{3:3}, at: n_tty_read+0xcf0/0x1230 drivers/tty/n_tty.c:2113
2 locks held by kworker/u4:7/9062:
1 lock held by syz-executor.1/32540:
#0: ffff88814087f348 (mapping.invalidate_lock#2){++++}-{3:3}, at: filemap_invalidate_lock include/linux/fs.h:828 [inline]
#0: ffff88814087f348 (mapping.invalidate_lock#2){++++}-{3:3}, at: blk_ioctl_zeroout block/ioctl.c:155 [inline]
#0: ffff88814087f348 (mapping.invalidate_lock#2){++++}-{3:3}, at: blkdev_common_ioctl+0xcae/0x1790 block/ioctl.c:459
1 lock held by syz-executor.3/32562:
1 lock held by syz-executor.3/32564:
1 lock held by syz-executor.2/32582:
#0: ffff88814087f348 (mapping.invalidate_lock#2){++++}-{3:3}, at: filemap_invalidate_lock include/linux/fs.h:828 [inline]
#0: ffff88814087f348 (mapping.invalidate_lock#2){++++}-{3:3}, at: blk_ioctl_zeroout block/ioctl.c:155 [inline]
#0: ffff88814087f348 (mapping.invalidate_lock#2){++++}-{3:3}, at: blkdev_common_ioctl+0xcae/0x1790 block/ioctl.c:459
1 lock held by syz-executor.5/32584:
#0: ffff88814087f348 (mapping.invalidate_lock#2){++++}-{3:3}, at: filemap_invalidate_lock include/linux/fs.h:828 [inline]
#0: ffff88814087f348 (mapping.invalidate_lock#2){++++}-{3:3}, at: blk_ioctl_zeroout block/ioctl.c:155 [inline]
#0: ffff88814087f348 (mapping.invalidate_lock#2){++++}-{3:3}, at: blkdev_common_ioctl+0xcae/0x1790 block/ioctl.c:459

=============================================

NMI backtrace for cpu 1
CPU: 1 PID: 27 Comm: khungtaskd Not tainted 5.16.0-rc2-next-20211125-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
nmi_cpu_backtrace.cold+0x47/0x144 lib/nmi_backtrace.c:111
nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62
trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:256 [inline]
watchdog+0xcb7/0xed0 kernel/hung_task.c:413
kthread+0x405/0x4f0 kernel/kthread.c:345
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
</TASK>
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 2958 Comm: systemd-journal Not tainted 5.16.0-rc2-next-20211125-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:check_kcov_mode kernel/kcov.c:166 [inline]
RIP: 0010:__sanitizer_cov_trace_pc+0x7/0x60 kernel/kcov.c:200
Code: 49 00 5d be 03 00 00 00 e9 06 e8 6a 02 66 0f 1f 44 00 00 48 8b be b0 01 00 00 e8 b4 ff ff ff 31 c0 c3 90 65 8b 05 19 8b 8a 7e <89> c1 48 8b 34 24 81 e1 00 01 00 00 65 48 8b 14 25 40 70 02 00 a9
RSP: 0018:ffffc90001aafdc8 EFLAGS: 00000293
RAX: 0000000080000000 RBX: ffff88802ca65a00 RCX: ffff88807b17ba80
RDX: 0000000000000000 RSI: ffff88807b17ba80 RDI: 0000000000000003
RBP: ffff8880aca65a00 R08: ffff8880aca65a00 R09: 000000000000002e
R10: ffffffff8134ed58 R11: 000000000000003f R12: 000000002ca65a00
R13: 000000000000002e R14: ffffea0000000000 R15: ffff88802ca65a00
FS: 00007f26fa2bd8c0(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f26f7c09000 CR3: 000000007f7df000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
phys_addr_valid arch/x86/mm/physaddr.h:7 [inline]
__phys_addr+0xa7/0x140 arch/x86/mm/physaddr.c:28
virt_to_head_page include/linux/mm.h:861 [inline]
qlink_to_cache mm/kasan/quarantine.c:120 [inline]
qlist_free_all+0x76/0xf0 mm/kasan/quarantine.c:162
kasan_quarantine_reduce+0x180/0x200 mm/kasan/quarantine.c:272
__kasan_slab_alloc+0xa2/0xc0 mm/kasan/common.c:444
kasan_slab_alloc include/linux/kasan.h:259 [inline]
slab_post_alloc_hook mm/slab.h:519 [inline]
slab_alloc_node mm/slub.c:3234 [inline]
slab_alloc mm/slub.c:3242 [inline]
kmem_cache_alloc+0x202/0x3a0 mm/slub.c:3247
getname_flags.part.0+0x50/0x4f0 fs/namei.c:138
getname_flags include/linux/audit.h:323 [inline]
getname fs/namei.c:217 [inline]
__do_sys_mkdir fs/namei.c:3929 [inline]
__se_sys_mkdir fs/namei.c:3927 [inline]
__x64_sys_mkdir+0xda/0x140 fs/namei.c:3927
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f26f9578687
Code: 00 b8 ff ff ff ff c3 0f 1f 40 00 48 8b 05 09 d8 2b 00 64 c7 00 5f 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 d7 2b 00 f7 d8 64 89 01 48
RSP: 002b:00007ffe28596978 EFLAGS: 00000293 ORIG_RAX: 0000000000000053
RAX: ffffffffffffffda RBX: 00007ffe28599890 RCX: 00007f26f9578687
RDX: 00007f26f9fe9a00 RSI: 00000000000001ed RDI: 0000564b999038a0
RBP: 00007ffe285969b0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000069 R11: 0000000000000293 R12: 0000000000000000
R13: 0000000000000000 R14: 00007ffe28599890 R15: 00007ffe28596ea0
</TASK>
----------------
Code disassembly (best guess):
0: 49 00 5d be rex.WB add %bl,-0x42(%r13)
4: 03 00 add (%rax),%eax
6: 00 00 add %al,(%rax)
8: e9 06 e8 6a 02 jmpq 0x26ae813
d: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
13: 48 8b be b0 01 00 00 mov 0x1b0(%rsi),%rdi
1a: e8 b4 ff ff ff callq 0xffffffd3
1f: 31 c0 xor %eax,%eax
21: c3 retq
22: 90 nop
23: 65 8b 05 19 8b 8a 7e mov %gs:0x7e8a8b19(%rip),%eax # 0x7e8a8b43
* 2a: 89 c1 mov %eax,%ecx <-- trapping instruction
2c: 48 8b 34 24 mov (%rsp),%rsi
30: 81 e1 00 01 00 00 and $0x100,%ecx
36: 65 48 8b 14 25 40 70 mov %gs:0x27040,%rdx
3d: 02 00
3f: a9 .byte 0xa9


---
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.

[Tetsuo Handa]

On 2022/04/02 16:20, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: f81e94e91878 Add linux-next specific files for 20211125
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=168d578db00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=be9183de0824e4d7
> dashboard link: https://syzkaller.appspot.com/bug?extid=4f1a237abaf14719db49
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>
> Unfortunately, I don't have any reproducer for this issue yet.

This is a known problem, and Christoph does not like a mitigation patch.
https://lkml.kernel.org/r/YgoQBTzb...@infradead.org

>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+4f1a23...@syzkaller.appspotmail.com

#syz dup: INFO: task hung in blkdev_fallocate

[Christoph Hellwig]

On Sat, Apr 02, 2022 at 08:26:23PM +0900, Tetsuo Handa wrote:
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=168d578db00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=be9183de0824e4d7
> > dashboard link: https://syzkaller.appspot.com/bug?extid=4f1a237abaf14719db49
> > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
>
> This is a known problem, and Christoph does not like a mitigation patch.
> https://lkml.kernel.org/r/YgoQBTzb...@infradead.org

And this report shows why: your patch makes the lock acquisition in
blkdev_fallocate killable. Which would not help with this problem at
all, as it does not come through blkdev_fallocate. The problem is that
the loop writing actual zeroes to the disk can take forever, and we
hold the invalidate_lock over that.

[Tetsuo Handa]

On 2022/04/04 13:58, Christoph Hellwig wrote:
> On Sat, Apr 02, 2022 at 08:26:23PM +0900, Tetsuo Handa wrote:
>>> git tree: linux-next
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=168d578db00000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=be9183de0824e4d7
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=4f1a237abaf14719db49
>>> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>>>
>>> Unfortunately, I don't have any reproducer for this issue yet.
>>
>> This is a known problem, and Christoph does not like a mitigation patch.
>> https://lkml.kernel.org/r/YgoQBTzb...@infradead.org
>
> And this report shows why: your patch makes the lock acquisition in
> blkdev_fallocate killable. Which would not help with this problem at
> all, as it does not come through blkdev_fallocate.

My patch proposes filemap_invalidate_lock_killable() and converts only
blkdev_fallocate() case as a starting point. Nothing prevents us from
converting e.g. blk_ioctl_zeroout() case as well. The "not come through
blkdev_fallocate" is bogus.

> The problem is that
> the loop writing actual zeroes to the disk can take forever, and we
> hold the invalidate_lock over that.

There can be several locations which cannot be converted to
filemap_invalidate_lock_killable() (like we had to use mutex_lock(&lo->lo_mutex)
for lo_release() case). But many locations can be converted to
filemap_invalidate_lock_killable() (like we use mutex_lock_killable(&lo->lo_mutex)
for almost all locations).

Being responsive to SIGKILL is good (even if we cannot afford making all locks
killable). I made many locations killable. Therefore, I wonder why not?

[Christoph Hellwig]

On Mon, Apr 04, 2022 at 02:12:14PM +0900, Tetsuo Handa wrote:
> On 2022/04/04 13:58, Christoph Hellwig wrote:
> > all, as it does not come through blkdev_fallocate.
>
> My patch proposes filemap_invalidate_lock_killable() and converts only
> blkdev_fallocate() case as a starting point. Nothing prevents us from
> converting e.g. blk_ioctl_zeroout() case as well. The "not come through
> blkdev_fallocate" is bogus.

Sure, we could try to convert most of the > 50 instances of
filemap_invalidate_lock to be killable. But that:

a) isn't what your patch actuall did
b) doesn't solve the underlying issue that is wasn't designed to to be
held over very extremely long running operations

Or to get back to what I said before - I don't think we can just hold
the lock over manually zeroing potentially gigabytes of blocks.

In other words: we'll need to chunk the zeroing up if we want
to hold the invalidate lock, I see no ther way to properly fix this.

[Tetsuo Handa]

On 2022/04/05 15:44, Christoph Hellwig wrote:
> On Mon, Apr 04, 2022 at 02:12:14PM +0900, Tetsuo Handa wrote:
>> On 2022/04/04 13:58, Christoph Hellwig wrote:
>> My patch proposes filemap_invalidate_lock_killable() and converts only
>> blkdev_fallocate() case as a starting point. Nothing prevents us from
>> converting e.g. blk_ioctl_zeroout() case as well. The "not come through
>> blkdev_fallocate" is bogus.
>
> Sure, we could try to convert most of the > 50 instances of
> filemap_invalidate_lock to be killable. But that:
>
> a) isn't what your patch actuall did

We can step by step convert all possible locations.

> b) doesn't solve the underlying issue that is wasn't designed to to be
> held over very extremely long running operations

Do you want to introduce state variables like Lo_rundown in order to
avoid holding this invalidate lock? That will be a lot of complication.

>
> Or to get back to what I said before - I don't think we can just hold
> the lock over manually zeroing potentially gigabytes of blocks.
>

Periodically releasing this invalidate lock may result in inconsistent
output. One can issue conflicting request (e.g. enlarging a file and
truncating that file). If truncate happens while partially enlarged (or
writing non-zero values while partially zeroed), resuming will need to
undo what was done during this invalidate lock was released. (Or do you
want to make conflicting requests fail with e.g. -EBUSY, possibly breaking
userspace programs?)

Serialization via holding throughout this zeroing/fallocate operation
is needed for returning consistent output.

> In other words: we'll need to chunk the zeroing up if we want
> to hold the invalidate lock, I see no ther way to properly fix this.

I don't think that we can chunk the zeroing/fallocate up, for
I don't think that we can determine appropriate chunk size.
It might be 4KB, it might be 1MB, it might be 1GB, but who knows which
size is safe for avoiding hung task warning on this invalidate lock.

The block device might be super slow (e.g. as slow as floppy disk, or
networking block device over very slow network). Also, hung task watchdog
timeout and concurrent requests colliding on this invalidate lock are not
visible to current thread doing actual zeroing/fallocate.

All we could afford will be to make this invalidate lock killable and
sometimes check fatal_signal_pending() inside zeroing/fallocate loop.