[syzbot] [xfs?] INFO: task hung in clean_bdev_aliases

6 views
Skip to first unread message

syzbot

unread,
Sep 5, 2023, 1:04:49 AM9/5/23
to djw...@kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, syzkall...@googlegroups.com
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: syzbot+1fa947...@syzkaller.appspotmail.com

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 syzk...@googlegroups.com.

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

Dave Chinner

unread,
Sep 5, 2023, 5:14:14 PM9/5/23
to syzbot, djw...@kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, syzkall...@googlegroups.com, linux...@vger.kernel.org, h...@lst.de
[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.

-Dave.
--
Dave Chinner
da...@fromorbit.com

Aleksandr Nogikh

unread,
Sep 6, 2023, 1:20:31 PM9/6/23
to Dave Chinner, syzbot, djw...@kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, syzkall...@googlegroups.com, linux...@vger.kernel.org, h...@lst.de
On Tue, Sep 5, 2023 at 11:14 PM 'Dave Chinner' via syzkaller-bugs
<syzkall...@googlegroups.com> 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 linu...@vger.kernel.org. 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?

--
Aleksandr

Darrick J. Wong

unread,
Sep 6, 2023, 2:04:07 PM9/6/23
to Aleksandr Nogikh, Dave Chinner, syzbot, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, syzkall...@googlegroups.com, linux...@vger.kernel.org, h...@lst.de
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
> <syzkall...@googlegroups.com> 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 linu...@vger.kernel.org. I can
> adjust the rules syzbot uses so that these are routed to "block".

Huh?

MAINTAINERS tells us that fs/iomap/ maps to "IOMAP FILESYSTEM LIBRARY",
why wouldn't it tag bugs with those stacktraces as "[iomap]" ?

They're separate subsystems that just happen to share the same vger
list because iomap was lifted from xfs.

> But should MAINTAINERS actually also not relate IOMAP FILESYSTEM
> LIBRARY with xfs in this case?

Did y'all try emailing those lists to ask how they'd like the function
name -> source file -> syzbot tagging set up?

--D

Christoph Hellwig

unread,
Sep 8, 2023, 4:28:51 AM9/8/23
to Aleksandr Nogikh, Dave Chinner, syzbot, djw...@kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, syzkall...@googlegroups.com, linux...@vger.kernel.org, h...@lst.de
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
> <syzkall...@googlegroups.com> 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 linu...@vger.kernel.org. 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 io...@lists.linux.dev 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

unread,
Sep 17, 2023, 11:35:07 AM9/17/23
to da...@fromorbit.com, djw...@kernel.org, h...@lst.de, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, nog...@google.com, syzkall...@googlegroups.com
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: syzbot+1fa947...@syzkaller.appspotmail.com

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>


---

syzbot

unread,
Sep 18, 2023, 10:52:40 PM9/18/23
to ax...@kernel.dk, bra...@kernel.org, da...@fromorbit.com, djw...@kernel.org, ha...@suse.de, h...@lst.de, johannes....@wdc.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, mcg...@kernel.org, nog...@google.com, p.ra...@samsung.com, syzkall...@googlegroups.com
syzbot has bisected this issue to:

commit 487c607df790d366e67a7d6a30adf785cdd98e55
Author: Christoph Hellwig <h...@lst.de>
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
Reported-by: syzbot+1fa947...@syzkaller.appspotmail.com
Fixes: 487c607df790 ("block: use iomap for writes to block devices")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Ricardo B. Marliere

unread,
Sep 19, 2023, 10:00:42 AM9/19/23
to syzbot, da...@fromorbit.com, djw...@kernel.org, h...@lst.de, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, nog...@google.com, syzkall...@googlegroups.com

syzbot

unread,
Sep 19, 2023, 10:38:40 AM9/19/23
to da...@fromorbit.com, djw...@kernel.org, h...@lst.de, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, nog...@google.com, ric...@marliere.net, syzkall...@googlegroups.com
Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
INFO: task hung in clean_bdev_aliases

INFO: task syz-executor.0:6797 blocked for more than 143 seconds.
Not tainted 6.6.0-rc2-next-20230919-syzkaller-06333-g29e400e3ea48 #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.0 state:D stack:26448 pid:6797 ppid:5409 flags:0x00004006
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5365 [inline]
__schedule+0xee1/0x5a00 kernel/sched/core.c:6677
schedule+0xe7/0x1b0 kernel/sched/core.c:6753
io_schedule+0xbe/0x130 kernel/sched/core.c:8953
folio_wait_bit_common+0x3dc/0x9c0 mm/filemap.c:1301
folio_lock include/linux/pagemap.h:1042 [inline]
clean_bdev_aliases+0x56b/0x610 fs/buffer.c:1732
clean_bdev_bh_alias include/linux/buffer_head.h:222 [inline]
__block_write_begin_int+0x8d6/0x14d0 fs/buffer.c:2125
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:1986 [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:51 [inline]
do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fd63bc7cae9
RSP: 002b:00007fd63ca7f0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 00007fd63bd9c050 RCX: 00007fd63bc7cae9
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000003
RBP: 00007fd63bcc847a R08: 0000000000000000 R09: 0000000000000000
R10: 0100000000000042 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000006e R14: 00007fd63bd9c050 R15: 00007ffca44145a8
</TASK>

Showing all locks held in the system:
1 lock held by khungtaskd/28:
#0: ffffffff8cba7260 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:303 [inline]
#0: ffffffff8cba7260 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:749 [inline]
#0: ffffffff8cba7260 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x75/0x340 kernel/locking/lockdep.c:6613
5 locks held by kworker/u4:6/958:
#0: ffff8880b993c758 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x29/0x130 kernel/sched/core.c:558
#1: ffff8880b9928888 (&per_cpu_ptr(group->pcpu, cpu)->seq){-.-.}-{0:0}, at: psi_task_switch+0x2d9/0x900 kernel/sched/psi.c:999
#2: ffff8880b99297d8 (&base->lock){-.-.}-{2:2}, at: lock_timer_base+0x5d/0x200 kernel/time/timer.c:999
#3: ffffffff924c2a00 (&obj_hash[i].lock){-.-.}-{2:2}, at: debug_object_activate+0x1a0/0x490 lib/debugobjects.c:717
#4: ffffffff9244f788 (&obj_hash[i].lock){-.-.}-{2:2}, at: debug_object_activate+0x1a0/0x490 lib/debugobjects.c:717
2 locks held by kworker/u4:12/1100:
#0: ffff8880b993c758 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x29/0x130 kernel/sched/core.c:558
#1: ffff8880b9928888 (&per_cpu_ptr(group->pcpu, cpu)->seq){-.-.}-{0:0}, at: psi_task_switch+0x2d9/0x900 kernel/sched/psi.c:999
2 locks held by getty/4786:
#0: ffff88814bf030a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x24/0x80 drivers/tty/tty_ldisc.c:243
#1: ffffc900020482f0 (&ldata->atomic_read_lock){+.+.}-{3:3}, at: n_tty_read+0xfc5/0x1480 drivers/tty/n_tty.c:2206
1 lock held by syz-executor.1/5410:
1 lock held by syz-executor.5/5418:
2 locks held by syz-executor.2/15785:
3 locks held by syz-executor.1/15788:
2 locks held by syz-executor.4/15793:

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

NMI backtrace for cpu 1
CPU: 1 PID: 28 Comm: khungtaskd Not tainted 6.6.0-rc2-next-20230919-syzkaller-06333-g29e400e3ea48 #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+0xf87/0x1210 kernel/hung_task.c:379
kthread+0x33c/0x440 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: 5049 Comm: kworker/0:4 Not tainted 6.6.0-rc2-next-20230919-syzkaller-06333-g29e400e3ea48 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Workqueue: events free_obj_work
RIP: 0010:unwind_next_frame+0x121c/0x2390 arch/x86/kernel/unwind_orc.c:665
Code: 79 11 00 00 4c 8b 6b 10 4c 39 ed 73 36 e8 3c c2 4c 00 4c 8d 75 08 4d 39 f4 73 28 e8 2e c2 4c 00 4d 39 f5 72 1e e8 24 c2 4c 00 <4c> 8b 7c 24 18 48 89 ee 4c 89 ff e8 24 bd 4c 00 49 39 ef 0f 83 50
RSP: 0018:ffffc9000374f778 EFLAGS: 00000093
RAX: 0000000000000000 RBX: ffffc9000374f850 RCX: 0000000000000000
RDX: ffff88807d000100 RSI: ffffffff813a678c RDI: ffffc9000374f860
RBP: ffffc9000374f848 R08: 0000000000000004 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: ffffc90003748000
R13: ffffc90003750000 R14: ffffc9000374f850 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2af98ffbc1 CR3: 000000002acf4000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<NMI>
</NMI>
<TASK>
__unwind_start+0x5a4/0x880 arch/x86/kernel/unwind_orc.c:760
unwind_start arch/x86/include/asm/unwind.h:64 [inline]
arch_stack_walk+0xaf/0x170 arch/x86/kernel/stacktrace.c:24
stack_trace_save+0x96/0xd0 kernel/stacktrace.c:122
kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
kasan_set_track+0x25/0x30 mm/kasan/common.c:52
kasan_save_free_info+0x28/0x40 mm/kasan/generic.c:522
____kasan_slab_free mm/kasan/common.c:236 [inline]
____kasan_slab_free+0x138/0x190 mm/kasan/common.c:200
kasan_slab_free include/linux/kasan.h:164 [inline]
__cache_free mm/slab.c:3370 [inline]
__do_kmem_cache_free mm/slab.c:3557 [inline]
kmem_cache_free+0x104/0x380 mm/slab.c:3582
free_obj_work+0x33d/0x630 lib/debugobjects.c:331
process_one_work+0x884/0x15c0 kernel/workqueue.c:2630
process_scheduled_works kernel/workqueue.c:2703 [inline]
worker_thread+0x8b9/0x1290 kernel/workqueue.c:2784
kthread+0x33c/0x440 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>


Tested on:

commit: 29e400e3 Add linux-next specific files for 20230919
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git next-20230919
console output: https://syzkaller.appspot.com/x/log.txt?x=10014938680000
kernel config: https://syzkaller.appspot.com/x/.config?x=e7a727b2649d5c9c
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

Note: no patches were applied.

Aleksandr Nogikh

unread,
Sep 20, 2023, 4:57:09 AM9/20/23
to Christoph Hellwig, Dave Chinner, syzbot, djw...@kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, syzkall...@googlegroups.com, linux...@vger.kernel.org
#syz set subsystems: iomap

Dave Chinner

unread,
Sep 20, 2023, 8:38:22 PM9/20/23
to Aleksandr Nogikh, Christoph Hellwig, syzbot, djw...@kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, syzkall...@googlegroups.com, linux...@vger.kernel.org
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 <h...@lst.de> 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 linu...@vger.kernel.org. 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 io...@lists.linux.dev 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
da...@fromorbit.com

Christoph Hellwig

unread,
Sep 25, 2023, 4:51:34 AM9/25/23
to syzbot, ax...@kernel.dk, bra...@kernel.org, da...@fromorbit.com, djw...@kernel.org, ha...@suse.de, h...@lst.de, johannes....@wdc.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, mcg...@kernel.org, nog...@google.com, p.ra...@samsung.com, syzkall...@googlegroups.com
#syz test: git://git.infradead.org/users/hch/misc.git bdev-iomap-fix

syzbot

unread,
Sep 25, 2023, 4:58:25 AM9/25/23
to ax...@kernel.dk, bra...@kernel.org, da...@fromorbit.com, djw...@kernel.org, ha...@suse.de, h...@infradead.org, h...@lst.de, johannes....@wdc.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, mcg...@kernel.org, nog...@google.com, p.ra...@samsung.com, syzkall...@googlegroups.com
Hello,

syzbot tried to test the proposed patch but the build/boot failed:

fs/buffer.c:2068:40: error: 'return' with a value, in function returning void [-Werror=return-type]


Tested on:

commit: b8908de1 iomap: add a workaround for racy i_size updat..
git tree: git://git.infradead.org/users/hch/misc.git bdev-iomap-fix
kernel config: https://syzkaller.appspot.com/x/.config?x=999148c170811772

Christoph Hellwig

unread,
Sep 25, 2023, 5:09:01 AM9/25/23
to syzbot, ax...@kernel.dk, bra...@kernel.org, da...@fromorbit.com, djw...@kernel.org, ha...@suse.de, h...@lst.de, johannes....@wdc.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, mcg...@kernel.org, nog...@google.com, p.ra...@samsung.com, syzkall...@googlegroups.com

syzbot

unread,
Sep 25, 2023, 5:35:18 AM9/25/23
to ax...@kernel.dk, bra...@kernel.org, da...@fromorbit.com, djw...@kernel.org, ha...@suse.de, h...@infradead.org, h...@lst.de, johannes....@wdc.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, mcg...@kernel.org, nog...@google.com, p.ra...@samsung.com, syzkall...@googlegroups.com
Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+1fa947...@syzkaller.appspotmail.com

Tested on:

commit: ca5e3ec4 iomap: add a workaround for racy i_size updat..
git tree: git://git.infradead.org/users/hch/misc.git bdev-iomap-fix
console output: https://syzkaller.appspot.com/x/log.txt?x=16d98efa680000
kernel config: https://syzkaller.appspot.com/x/.config?x=710dc49bece494df
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

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.
Reply all
Reply to author
Forward
0 new messages