Hello,
syzbot found the following issue on:
HEAD commit: 92901222f83d Merge tag 'f2fs-for-6-6-rc1' of git://git.ker..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1485e78fa80000
kernel config: https://syzkaller.appspot.com/x/.config?x=3bd57a1ac08277b0
dashboard link: https://syzkaller.appspot.com/bug?extid=1fa947e7f09e136925b8
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13fcf738680000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/ee486d884228/disk-92901222.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b5187db0b1d1/vmlinux-92901222.xz
kernel image: https://storage.googleapis.com/syzbot-assets/82c4e42d693e/bzImage-92901222.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
INFO: task syz-executor.5:10017 blocked for more than 143 seconds.
Not tainted 6.5.0-syzkaller-11075-g92901222f83d #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.5 state:D stack:27624 pid:10017 ppid:5071 flags:0x00004006
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5382 [inline]
__schedule+0xee1/0x59f0 kernel/sched/core.c:6695
schedule+0xe7/0x1b0 kernel/sched/core.c:6771
io_schedule+0xbe/0x130 kernel/sched/core.c:9026
folio_wait_bit_common+0x3d2/0x9b0 mm/filemap.c:1304
folio_lock include/linux/pagemap.h:1042 [inline]
clean_bdev_aliases+0x56b/0x610 fs/buffer.c:1725
clean_bdev_bh_alias include/linux/buffer_head.h:219 [inline]
__block_write_begin_int+0x8d6/0x1470 fs/buffer.c:2115
iomap_write_begin+0x5be/0x17b0 fs/iomap/buffered-io.c:772
iomap_write_iter fs/iomap/buffered-io.c:907 [inline]
iomap_file_buffered_write+0x3d6/0x9a0 fs/iomap/buffered-io.c:968
blkdev_buffered_write block/fops.c:634 [inline]
blkdev_write_iter+0x572/0xca0 block/fops.c:688
call_write_iter include/linux/fs.h:1985 [inline]
do_iter_readv_writev+0x21e/0x3c0 fs/read_write.c:735
do_iter_write+0x17f/0x830 fs/read_write.c:860
vfs_iter_write+0x7a/0xb0 fs/read_write.c:901
iter_file_splice_write+0x698/0xbf0 fs/splice.c:736
do_splice_from fs/splice.c:933 [inline]
direct_splice_actor+0x118/0x180 fs/splice.c:1142
splice_direct_to_actor+0x347/0xa30 fs/splice.c:1088
do_splice_direct+0x1af/0x280 fs/splice.c:1194
do_sendfile+0xb88/0x1390 fs/read_write.c:1254
__do_sys_sendfile64 fs/read_write.c:1322 [inline]
__se_sys_sendfile64 fs/read_write.c:1308 [inline]
__x64_sys_sendfile64+0x1d6/0x220 fs/read_write.c:1308
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fdb8ca7cae9
RSP: 002b:00007ffcd642da18 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 00007fdb8cb9bf80 RCX: 00007fdb8ca7cae9
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000003
RBP: 00007fdb8cac847a R08: 0000000000000000 R09: 0000000000000000
R10: 0100000000000042 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000be7 R14: 00007fdb8cb9bf80 R15: 00007fdb8cb9bf80
</TASK>
INFO: lockdep is turned off.
NMI backtrace for cpu 1
CPU: 1 PID: 29 Comm: khungtaskd Not tainted 6.5.0-syzkaller-11075-g92901222f83d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
nmi_cpu_backtrace+0x277/0x380 lib/nmi_backtrace.c:113
nmi_trigger_cpumask_backtrace+0x299/0x300 lib/nmi_backtrace.c:62
trigger_all_cpu_backtrace include/linux/nmi.h:160 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:222 [inline]
watchdog+0xfac/0x1230 kernel/hung_task.c:379
kthread+0x33a/0x430 kernel/kthread.c:388
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
</TASK>
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 17 Comm: rcu_preempt Not tainted 6.5.0-syzkaller-11075-g92901222f83d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
RIP: 0010:load_balance+0x10a/0x3130 kernel/sched/fair.c:10983
Code: 4a 8d 3c f5 40 aa 5c 8c 48 ba 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 80 3c 11 00 0f 85 2f 2e 00 00 31 c0 b9 0c 00 00 00 <4e> 8b 1c f5 40 aa 5c 8c 4c 89 94 24 f8 00 00 00 48 8d bc 24 00 01
RSP: 0018:ffffc900001676c8 EFLAGS: 00000046
RAX: 0000000000000000 RBX: ffff8880b983c700 RCX: 000000000000000c
RDX: dffffc0000000000 RSI: ffffffff8ae90360 RDI: ffffffff8c5caa40
RBP: ffffc90000167898 R08: ffffc90000167960 R09: 0000000000000000
R10: ffff88801525ac00 R11: 0000000000000000 R12: 00000000000287d8
R13: ffffc90000167960 R14: 0000000000000000 R15: 0000000100004d48
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000240 CR3: 000000000c976000 CR4: 0000000000350ef0
Call Trace:
<NMI>
</NMI>
<TASK>
newidle_balance+0x710/0x1210 kernel/sched/fair.c:12059
pick_next_task_fair+0x87/0x1200 kernel/sched/fair.c:8234
__pick_next_task kernel/sched/core.c:6004 [inline]
pick_next_task kernel/sched/core.c:6079 [inline]
__schedule+0x493/0x59f0 kernel/sched/core.c:6659
schedule+0xe7/0x1b0 kernel/sched/core.c:6771
schedule_timeout+0x157/0x2c0 kernel/time/timer.c:2167
rcu_gp_fqs_loop+0x1ec/0xa50 kernel/rcu/tree.c:1613
rcu_gp_kthread+0x249/0x380 kernel/rcu/tree.c:1812
kthread+0x33a/0x430 kernel/kthread.c:388
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
</TASK>
---
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 [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
On Wed, Sep 06, 2023 at 07:20:15PM +0200, Aleksandr Nogikh wrote:
> On Tue, Sep 5, 2023 at 11:14 PM 'Dave Chinner' via syzkaller-bugs
> <[email protected]> wrote:
> >
> > [cc linux-block, Christoph]
> >
> > Another iomap-blockdev related issue.
> >
> > #syz set subsystems: block
> >
> > syzbot developers: Please review how you are classifying subsystems,
> > this is the third false XFS classification in 24 hours.
>
> The reason why syzbot marked this report as xfs is that, per
> MAINTAINERS, fs/iomap/ points to [email protected]. I can
> adjust the rules syzbot uses so that these are routed to "block".
>
> But should MAINTAINERS actually also not relate IOMAP FILESYSTEM
> LIBRARY with xfs in this case?
I'd tag it with iomap, as it's a different subsystem just sharing
the mailing list. We also have [email protected] for both the
iommu and dma-mapping subsystems as a similar example.
But what's also important for issues like this is that often the
called library code (in this case iomap) if often not, or only
partially at fault. So capturing the calling context (in this
case block) might also be useful.
And to get out of these meta discussions: I'll look into the actual
issues in a bit, I'll try to find time despite travelling.
syzbot has found a reproducer for the following issue on:
HEAD commit: f0b0d403eabb Merge tag 'kbuild-fixes-v6.6' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14bbe63c680000
kernel config: https://syzkaller.appspot.com/x/.config?x=999148c170811772
dashboard link: https://syzkaller.appspot.com/bug?extid=1fa947e7f09e136925b8
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16148d74680000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13e10762680000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/9067aea1d6b6/disk-f0b0d403.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/5b837ae6375f/vmlinux-f0b0d403.xz
kernel image: https://storage.googleapis.com/syzbot-assets/4b1678667256/bzImage-f0b0d403.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
INFO: task syz-executor119:9037 blocked for more than 143 seconds.
Not tainted 6.6.0-rc1-syzkaller-00240-gf0b0d403eabb #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor119 state:D stack:25872 pid:9037 ppid:5100 flags:0x00004006
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5382 [inline]
__schedule+0xee1/0x59f0 kernel/sched/core.c:6695
schedule+0xe7/0x1b0 kernel/sched/core.c:6771
io_schedule+0xbe/0x130 kernel/sched/core.c:9026
folio_wait_bit_common+0x3d2/0x9b0 mm/filemap.c:1301
folio_lock include/linux/pagemap.h:1042 [inline]
clean_bdev_aliases+0x56b/0x610 fs/buffer.c:1725
clean_bdev_bh_alias include/linux/buffer_head.h:219 [inline]
__block_write_begin_int+0x8d6/0x1470 fs/buffer.c:2115
iomap_write_begin+0x5be/0x17b0 fs/iomap/buffered-io.c:772
iomap_write_iter fs/iomap/buffered-io.c:907 [inline]
iomap_file_buffered_write+0x3d6/0x9a0 fs/iomap/buffered-io.c:968
blkdev_buffered_write block/fops.c:634 [inline]
blkdev_write_iter+0x4f5/0xc90 block/fops.c:684
call_write_iter include/linux/fs.h:1985 [inline]
do_iter_readv_writev+0x21e/0x3c0 fs/read_write.c:735
do_iter_write+0x17f/0x830 fs/read_write.c:860
vfs_iter_write+0x7a/0xb0 fs/read_write.c:901
iter_file_splice_write+0x698/0xbf0 fs/splice.c:736
do_splice_from fs/splice.c:933 [inline]
direct_splice_actor+0x118/0x180 fs/splice.c:1142
splice_direct_to_actor+0x347/0xa30 fs/splice.c:1088
do_splice_direct+0x1af/0x280 fs/splice.c:1194
do_sendfile+0xb88/0x1390 fs/read_write.c:1254
__do_sys_sendfile64 fs/read_write.c:1322 [inline]
__se_sys_sendfile64 fs/read_write.c:1308 [inline]
__x64_sys_sendfile64+0x1d6/0x220 fs/read_write.c:1308
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f92485ce3b9
RSP: 002b:00007f9248583158 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 00007f924864e3e8 RCX: 00007f92485ce3b9
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000003
RBP: 00007f924864e3e0 R08: 00007f92485836c0 R09: 0000000000000000
R10: 0100000000000042 R11: 0000000000000246 R12: 00007f924864e3ec
R13: 0000000000000016 R14: 00007ffd0b251ce0 R15: 00007ffd0b251dc8
</TASK>
Showing all locks held in the system:
1 lock held by khungtaskd/28:
#0: ffffffff8cba7860 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x55/0x340 kernel/locking/lockdep.c:6607
2 locks held by getty/4793:
#0: ffff888027bb90a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x24/0x80 drivers/tty/tty_ldisc.c:243
#1: ffffc900020682f0 (&ldata->atomic_read_lock){+.+.}-{3:3}, at: n_tty_read+0xfc5/0x1480 drivers/tty/n_tty.c:2206
3 locks held by syz-executor119/5099:
3 locks held by syz-executor119/5105:
=============================================
NMI backtrace for cpu 1
CPU: 1 PID: 28 Comm: khungtaskd Not tainted 6.6.0-rc1-syzkaller-00240-gf0b0d403eabb #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
nmi_cpu_backtrace+0x277/0x380 lib/nmi_backtrace.c:113
nmi_trigger_cpumask_backtrace+0x299/0x300 lib/nmi_backtrace.c:62
trigger_all_cpu_backtrace include/linux/nmi.h:160 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:222 [inline]
watchdog+0xfac/0x1230 kernel/hung_task.c:379
kthread+0x33a/0x430 kernel/kthread.c:388
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
</TASK>
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 5097 Comm: syz-executor119 Not tainted 6.6.0-rc1-syzkaller-00240-gf0b0d403eabb #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
RIP: 0010:orc_find arch/x86/kernel/unwind_orc.c:217 [inline]
RIP: 0010:unwind_next_frame+0x25f/0x2390 arch/x86/kernel/unwind_orc.c:494
Code: 83 f4 19 00 00 e8 61 83 4c 00 45 89 ee 48 b8 00 00 00 00 00 fc ff df 4a 8d 3c b5 44 d7 00 90 48 89 fa 48 c1 ea 03 0f b6 14 02 <48> 89 f8 83 e0 07 83 c0 03 38 d0 7c 09 84 d2 74 05 e8 db 83 a1 00
RSP: 0018:ffffc9000030f510 EFLAGS: 00000a03
RAX: dffffc0000000000 RBX: ffffc9000030f590 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff813a49af RDI: ffffffff90043a8c
RBP: 0000000000000001 R08: 0000000000000004 R09: 000000000000d8d2
R10: 0000000000098000 R11: dffffc0000000000 R12: ffffffff81d8d288
R13: 000000000000d8d2 R14: 000000000000d8d2 R15: ffffc9000030f5c5
FS: 0000555556536480(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555556540808 CR3: 000000007a917000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<NMI>
</NMI>
<TASK>
arch_stack_walk+0xfa/0x170 arch/x86/kernel/stacktrace.c:25
stack_trace_save+0x96/0xd0 kernel/stacktrace.c:122
save_stack+0x160/0x1f0 mm/page_owner.c:128
__set_page_owner+0x1f/0x60 mm/page_owner.c:192
set_page_owner include/linux/page_owner.h:31 [inline]
post_alloc_hook+0x2cf/0x340 mm/page_alloc.c:1536
prep_new_page mm/page_alloc.c:1543 [inline]
get_page_from_freelist+0xee0/0x2f20 mm/page_alloc.c:3170
__alloc_pages+0x1d0/0x4a0 mm/page_alloc.c:4426
alloc_pages+0x1a9/0x270 mm/mempolicy.c:2298
__get_free_pages+0xc/0x40 mm/page_alloc.c:4477
_pgd_alloc arch/x86/mm/pgtable.c:420 [inline]
pgd_alloc+0x28/0x260 arch/x86/mm/pgtable.c:436
mm_alloc_pgd kernel/fork.c:795 [inline]
mm_init+0x679/0xf60 kernel/fork.c:1298
dup_mm kernel/fork.c:1683 [inline]
copy_mm kernel/fork.c:1735 [inline]
copy_process+0x6bf8/0x7400 kernel/fork.c:2501
kernel_clone+0xfd/0x930 kernel/fork.c:2909
__do_sys_clone+0xba/0x100 kernel/fork.c:3052
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f92485cc1a3
Code: 1f 84 00 00 00 00 00 64 48 8b 04 25 10 00 00 00 45 31 c0 31 d2 31 f6 bf 11 00 20 01 4c 8d 90 d0 02 00 00 b8 38 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 89 c2 85 c0 75 2c 64 48 8b 04 25 10 00 00
RSP: 002b:00007ffd0b251da8 EFLAGS: 00000246 ORIG_RAX: 0000000000000038
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f92485cc1a3
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000001200011
RBP: 0000000000000000 R08: 0000000000000000 R09: 00007ffd0b251c44
R10: 0000555556536750 R11: 0000000000000246 R12: 0000000000000001
R13: 431bde82d7b634db R14: 000000000012b3f1 R15: 00007ffd0b251f20
</TASK>
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
syzbot has bisected this issue to:
commit 487c607df790d366e67a7d6a30adf785cdd98e55
Author: Christoph Hellwig <[email protected]>
Date: Tue Aug 1 17:22:00 2023 +0000
block: use iomap for writes to block devices
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1086cb74680000
start commit: f0b0d403eabb Merge tag 'kbuild-fixes-v6.6' of git://git.ke..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=1286cb74680000
console output: https://syzkaller.appspot.com/x/log.txt?x=1486cb74680000
kernel config: https://syzkaller.appspot.com/x/.config?x=999148c170811772
dashboard link: https://syzkaller.appspot.com/bug?extid=1fa947e7f09e136925b8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16148d74680000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13e10762680000
Reported-by: [email protected]
Fixes: 487c607df790 ("block: use iomap for writes to block devices")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git next-20230919
#syz set subsystems: iomap
On Fri, Sep 8, 2023 at 10:28 AM Christoph Hellwig <[email protected]> wrote:
>
> On Wed, Sep 06, 2023 at 07:20:15PM +0200, Aleksandr Nogikh wrote:
> >
> > The reason why syzbot marked this report as xfs is that, per
> > MAINTAINERS, fs/iomap/ points to [email protected]. I can
> > adjust the rules syzbot uses so that these are routed to "block".
> >
> > But should MAINTAINERS actually also not relate IOMAP FILESYSTEM
> > LIBRARY with xfs in this case?
>
> I'd tag it with iomap, as it's a different subsystem just sharing
> the mailing list. We also have [email protected] for both the
> iommu and dma-mapping subsystems as a similar example.
>
> But what's also important for issues like this is that often the
> called library code (in this case iomap) if often not, or only
> partially at fault. So capturing the calling context (in this
> case block) might also be useful.
>
> And to get out of these meta discussions: I'll look into the actual
> issues in a bit, I'll try to find time despite travelling.
>
On Wed, Sep 20, 2023 at 10:56:56AM +0200, Aleksandr Nogikh wrote:
> # set subsystems: iomap
No. As I said when I originally reassigned this from XFS to the
block subsystem, this is a regression caused by changes to the block
device code. Just because that overall change was to use iomap for
block devices, that doesn't make it an iomap regression or the
responsibility of XFS or iomap maintainers to triage and fix this
block device regression.
> On Fri, Sep 8, 2023 at 10:28 AM Christoph Hellwig <[email protected]> wrote:
> >
> > On Wed, Sep 06, 2023 at 07:20:15PM +0200, Aleksandr Nogikh wrote:
> > >
> > > The reason why syzbot marked this report as xfs is that, per
> > > MAINTAINERS, fs/iomap/ points to [email protected]. I can
> > > adjust the rules syzbot uses so that these are routed to "block".
> > >
> > > But should MAINTAINERS actually also not relate IOMAP FILESYSTEM
> > > LIBRARY with xfs in this case?
> >
> > I'd tag it with iomap, as it's a different subsystem just sharing
> > the mailing list. We also have [email protected] for both the
> > iommu and dma-mapping subsystems as a similar example.
> >
> > But what's also important for issues like this is that often the
> > called library code (in this case iomap) if often not, or only
> > partially at fault. So capturing the calling context (in this
> > case block) might also be useful.
Which is exactly what Christoph also said.
Please don't conflate a discussion about the incorrect assignment
by syzbot (i.e. associating iomap with XFS because of a shared
mailing list) with the actual problem that was initially reported.
So, set this back to the block subsystem where it actually belongs.
#syz set subsystems: block
-Dave
--
Dave Chinner
[email protected]
#syz test: git://git.infradead.org/users/hch/misc.git bdev-iomap-fix