[syzbot] [jfs?] INFO: task hung in path_mount (2)

[syzbot] [jfs?] INFO: task hung in path_mount (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    2ccdd1b13c59 Linux 6.5-rc6
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16990d53a80000
kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14265373a80000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/ecb74567efdf/disk-2ccdd1b1.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/347764e4bb8e/vmlinux-2ccdd1b1.xz
kernel image: https://storage.googleapis.com/syzbot-assets/84f1d2de7e10/bzImage-2ccdd1b1.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/21e9fff65e06/mount_0.gz

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

INFO: task syz-executor415:5343 blocked for more than 143 seconds.
      Not tainted 6.5.0-rc6-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor415 state:D stack:25032 pid:5343  ppid:5095   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:6845
 rwsem_down_write_slowpath+0xedd/0x13a0 kernel/locking/rwsem.c:1178
 __down_write_common+0x1aa/0x200 kernel/locking/rwsem.c:1306
 do_remount fs/namespace.c:2879 [inline]
 path_mount+0xbdd/0xfa0 fs/namespace.c:3654
 do_mount fs/namespace.c:3675 [inline]
 __do_sys_mount fs/namespace.c:3884 [inline]
 __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f917fa53c0a
RSP: 002b:00007ffd6ff7f3a8 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007f917fa53c0a
RDX: 0000000020000180 RSI: 0000000020000100 RDI: 0000000000000000
RBP: 00007ffd6ff7f440 R08: 00007ffd6ff7f440 R09: 0000000000000000
R10: 0000000001a404ac R11: 0000000000000286 R12: 0000000020000100
R13: 0000000020000180 R14: 0000000000000000 R15: 0000000020003600
 </TASK>
INFO: task syz-executor415:5344 blocked for more than 143 seconds.
      Not tainted 6.5.0-rc6-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor415 state:D stack:25032 pid:5344  ppid:5089   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 jfs_flush_journal+0x733/0xec0 fs/jfs/jfs_logmgr.c:1564
 jfs_sync_fs+0x80/0xa0 fs/jfs/super.c:684
 dquot_quota_sync+0xdb/0x490 fs/quota/dquot.c:704
 iterate_supers+0x12b/0x1e0 fs/super.c:744
 quota_sync_all fs/quota/quota.c:69 [inline]
 __do_sys_quotactl fs/quota/quota.c:938 [inline]
 __se_sys_quotactl+0x391/0xa30 fs/quota/quota.c:917
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f917fa525d9
RSP: 002b:00007ffd6ff7f588 EFLAGS: 00000246 ORIG_RAX: 00000000000000b3
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f917fa525d9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff80000101
RBP: 0000000000000000 R08: 0000000000005d70 R09: 00007ffd6ff7f5b8
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd6ff7f5b8
R13: 000000000000001f R14: 00007ffd6ff7f5f0 R15: 431bde82d7b634db
 </TASK>
INFO: task syz-executor415:5345 blocked for more than 143 seconds.
      Not tainted 6.5.0-rc6-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor415 state:D stack:25032 pid:5345  ppid:5087   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:6845
 rwsem_down_read_slowpath+0x5f4/0x950 kernel/locking/rwsem.c:1086
 __down_read_common kernel/locking/rwsem.c:1250 [inline]
 __down_read kernel/locking/rwsem.c:1263 [inline]
 down_read+0x9c/0x2f0 kernel/locking/rwsem.c:1522
 iterate_supers+0xb0/0x1e0 fs/super.c:742
 quota_sync_all fs/quota/quota.c:69 [inline]
 __do_sys_quotactl fs/quota/quota.c:938 [inline]
 __se_sys_quotactl+0x391/0xa30 fs/quota/quota.c:917
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f917fa525d9
RSP: 002b:00007ffd6ff7f588 EFLAGS: 00000246 ORIG_RAX: 00000000000000b3
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f917fa525d9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff80000101
RBP: 0000000000000000 R08: 0000000000005d70 R09: 00007ffd6ff7f5b8
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd6ff7f5b8
R13: 000000000000001d R14: 00007ffd6ff7f5f0 R15: 431bde82d7b634db
 </TASK>
INFO: task syz-executor415:5346 blocked for more than 144 seconds.
      Not tainted 6.5.0-rc6-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor415 state:D stack:25032 pid:5346  ppid:5084   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:6845
 rwsem_down_read_slowpath+0x5f4/0x950 kernel/locking/rwsem.c:1086
 __down_read_common kernel/locking/rwsem.c:1250 [inline]
 __down_read kernel/locking/rwsem.c:1263 [inline]
 down_read+0x9c/0x2f0 kernel/locking/rwsem.c:1522
 iterate_supers+0xb0/0x1e0 fs/super.c:742
 quota_sync_all fs/quota/quota.c:69 [inline]
 __do_sys_quotactl fs/quota/quota.c:938 [inline]
 __se_sys_quotactl+0x391/0xa30 fs/quota/quota.c:917
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f917fa525d9
RSP: 002b:00007ffd6ff7f588 EFLAGS: 00000246 ORIG_RAX: 00000000000000b3
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f917fa525d9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff80000101
RBP: 0000000000000000 R08: 0000000000005d70 R09: 00007ffd6ff7f5b8
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd6ff7f5b8
R13: 000000000000001d R14: 00007ffd6ff7f5f0 R15: 431bde82d7b634db
 </TASK>
INFO: task syz-executor415:5347 blocked for more than 144 seconds.
      Not tainted 6.5.0-rc6-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor415 state:D stack:25032 pid:5347  ppid:5086   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:6845
 rwsem_down_read_slowpath+0x5f4/0x950 kernel/locking/rwsem.c:1086
 __down_read_common kernel/locking/rwsem.c:1250 [inline]
 __down_read kernel/locking/rwsem.c:1263 [inline]
 down_read+0x9c/0x2f0 kernel/locking/rwsem.c:1522
 iterate_supers+0xb0/0x1e0 fs/super.c:742
 quota_sync_all fs/quota/quota.c:69 [inline]
 __do_sys_quotactl fs/quota/quota.c:938 [inline]
 __se_sys_quotactl+0x391/0xa30 fs/quota/quota.c:917
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f917fa525d9
RSP: 002b:00007ffd6ff7f588 EFLAGS: 00000246 ORIG_RAX: 00000000000000b3
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f917fa525d9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff80000101
RBP: 0000000000000000 R08: 0000000000005d70 R09: 00007ffd6ff7f5b8
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd6ff7f5b8
R13: 000000000000001e R14: 00007ffd6ff7f5f0 R15: 431bde82d7b634db
 </TASK>
INFO: task syz-executor415:5348 blocked for more than 144 seconds.
      Not tainted 6.5.0-rc6-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor415 state:D stack:25384 pid:5348  ppid:5088   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:6845
 rwsem_down_read_slowpath+0x5f4/0x950 kernel/locking/rwsem.c:1086
 __down_read_common kernel/locking/rwsem.c:1250 [inline]
 __down_read kernel/locking/rwsem.c:1263 [inline]
 down_read+0x9c/0x2f0 kernel/locking/rwsem.c:1522
 iterate_supers+0xb0/0x1e0 fs/super.c:742
 quota_sync_all fs/quota/quota.c:69 [inline]
 __do_sys_quotactl fs/quota/quota.c:938 [inline]
 __se_sys_quotactl+0x391/0xa30 fs/quota/quota.c:917
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f917fa525d9
RSP: 002b:00007ffd6ff7f588 EFLAGS: 00000246 ORIG_RAX: 00000000000000b3
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f917fa525d9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff80000101
RBP: 0000000000000000 R08: 0000000000005d70 R09: 00007ffd6ff7f5b8
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd6ff7f5b8
R13: 000000000000001e R14: 00007ffd6ff7f5f0 R15: 431bde82d7b634db
 </TASK>

Showing all locks held in the system:
1 lock held by rcu_tasks_kthre/13:
 #0: ffffffff8d3295b0 (rcu_tasks.tasks_gp_mutex){+.+.}-{3:3}, at: rcu_tasks_one_gp+0x29/0xd20 kernel/rcu/tasks.h:522
1 lock held by rcu_tasks_trace/14:
 #0: ffffffff8d329970 (rcu_tasks_trace.tasks_gp_mutex){+.+.}-{3:3}, at: rcu_tasks_one_gp+0x29/0xd20 kernel/rcu/tasks.h:522
1 lock held by khungtaskd/28:
 #0: ffffffff8d3293e0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x0/0x30
2 locks held by getty/4779:
 #0: ffff8880291c2098 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
 #1: ffffc900015b02f0 (&ldata->atomic_read_lock){+.+.}-{3:3}, at: n_tty_read+0x6b1/0x1dc0 drivers/tty/n_tty.c:2187
2 locks held by kworker/u4:5/5177:
 #0: ffff8880b983bf98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2a/0x140 kernel/sched/core.c:558
 #1: ffff8880b98287c8 (&per_cpu_ptr(group->pcpu, cpu)->seq){-.-.}-{0:0}, at: psi_task_switch+0x3a7/0x770 kernel/sched/psi.c:987
1 lock held by syz-executor415/5343:
 #0: ffff88807aef40e0 (&type->s_umount_key#65){++++}-{3:3}, at: do_remount fs/namespace.c:2879 [inline]
 #0: ffff88807aef40e0 (&type->s_umount_key#65){++++}-{3:3}, at: path_mount+0xbdd/0xfa0 fs/namespace.c:3654
1 lock held by syz-executor415/5344:
 #0: ffff88807aef40e0 (&type->s_umount_key#65){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor415/5345:
 #0: ffff88807aef40e0 (&type->s_umount_key#65){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor415/5346:
 #0: ffff88807aef40e0 (&type->s_umount_key#65){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor415/5347:
 #0: ffff88807aef40e0 (&type->s_umount_key#65){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor415/5348:
 #0: ffff88807aef40e0 (&type->s_umount_key#65){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742

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

NMI backtrace for cpu 1
CPU: 1 PID: 28 Comm: khungtaskd Not tainted 6.5.0-rc6-syzkaller #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+0x1e7/0x2d0 lib/dump_stack.c:106
 nmi_cpu_backtrace+0x498/0x4d0 lib/nmi_backtrace.c:113
 nmi_trigger_cpumask_backtrace+0x187/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+0xec2/0xf00 kernel/hung_task.c:379
 kthread+0x2b8/0x350 kernel/kthread.c:389
 ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145
 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: 41 Comm: kworker/u4:2 Not tainted 6.5.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
Workqueue: bat_events batadv_mcast_mla_update
RIP: 0010:__orc_find arch/x86/kernel/unwind_orc.c:102 [inline]
RIP: 0010:orc_find arch/x86/kernel/unwind_orc.c:227 [inline]
RIP: 0010:unwind_next_frame+0x495/0x2390 arch/x86/kernel/unwind_orc.c:494
Code: 48 89 d8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df 0f b6 04 08 84 c0 75 27 48 63 03 48 01 d8 48 8d 4b 04 4c 39 f8 4c 0f 46 e9 <48> 8d 43 fc 48 0f 47 e8 4c 0f 46 e3 49 39 ed 76 a8 e9 aa fd ff ff
RSP: 0018:ffffc90000b27510 EFLAGS: 00000293
RAX: ffffffff81e45b18 RBX: ffffffff8eaf4d20 RCX: ffffffff8eaf4d24
RDX: ffffffff8f205ef4 RSI: 00000000000a0001 RDI: ffffffff813c8bc0
RBP: ffffffff8eaf4d28 R08: 0000000000000011 R09: ffffc90000b276d0
R10: ffffc90000b27630 R11: fffff52000164ec8 R12: ffffffff8eaf4d18
R13: ffffffff8eaf4d24 R14: ffffffff8eaf4d0c R15: ffffffff81e45b5e
FS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055a25c82a600 CR3: 000000000d130000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <NMI>
 </NMI>
 <TASK>
 arch_stack_walk+0x111/0x140 arch/x86/kernel/stacktrace.c:25
 stack_trace_save+0x117/0x1c0 kernel/stacktrace.c:122
 kasan_save_stack mm/kasan/common.c:45 [inline]
 kasan_set_track+0x4f/0x70 mm/kasan/common.c:52
 kasan_save_free_info+0x28/0x40 mm/kasan/generic.c:522
 ____kasan_slab_free+0xd6/0x120 mm/kasan/common.c:236
 kasan_slab_free include/linux/kasan.h:162 [inline]
 slab_free_hook mm/slub.c:1792 [inline]
 slab_free_freelist_hook mm/slub.c:1818 [inline]
 slab_free mm/slub.c:3801 [inline]
 __kmem_cache_free+0x25f/0x3b0 mm/slub.c:3814
 batadv_mcast_mla_list_free net/batman-adv/multicast.c:638 [inline]
 __batadv_mcast_mla_update net/batman-adv/multicast.c:893 [inline]
 batadv_mcast_mla_update+0x380a/0x3bb0 net/batman-adv/multicast.c:915
 process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600
 worker_thread+0xa63/0x1210 kernel/workqueue.c:2751
 kthread+0x2b8/0x350 kernel/kthread.c:389
 ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145
 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 syzkaller@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

Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

[syzbot]

syzbot suspects this issue was fixed by commit:

commit 6f861765464f43a71462d52026fbddfc858239a5
Author: Jan Kara <jack@suse.cz>
Date:   Wed Nov 1 17:43:10 2023 +0000

    fs: Block writes to mounted block devices

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
start commit:   2ccdd1b13c59 Linux 6.5-rc6
git tree:       upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14265373a80000

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: fs: Block writes to mounted block devices

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

Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

[Christian Brauner]

On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
> 
> commit 6f861765464f43a71462d52026fbddfc858239a5
> Author: Jan Kara <jack@suse.cz>
> Date:   Wed Nov 1 17:43:10 2023 +0000
> 
>     fs: Block writes to mounted block devices
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> start commit:   2ccdd1b13c59 Linux 6.5-rc6
> git tree:       upstream
> kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> 
> If the result looks correct, please mark the issue as fixed by replying with:
 
#syz fix: fs: Block writes to mounted block devices

Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

[Jens Axboe]

On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <brauner@kernel.org> wrote:
>
> On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> > syzbot suspects this issue was fixed by commit:
> >
> > commit 6f861765464f43a71462d52026fbddfc858239a5
> > Author: Jan Kara <jack@suse.cz>
> > Date:   Wed Nov 1 17:43:10 2023 +0000
> >
> >     fs: Block writes to mounted block devices
> >
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> > start commit:   2ccdd1b13c59 Linux 6.5-rc6
> > git tree:       upstream
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> > dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> >
> > If the result looks correct, please mark the issue as fixed by replying with:
>
> #syz fix: fs: Block writes to mounted block devices

Like Dave replied a few days ago, I'm kind of skeptical on all of these
bugs being closed by this change. I'm guessing that they are all
resolved now because a) the block writes while mounted option was set to
Y, and b) the actual bug is just masked by that.

Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
really fixed, and what happens if someone doesn't turn on that option?
If it's required, perhaps it should not be an option at all? Though
that'd seem to be likely to break some funky use cases, whether they are
valid or not.

-- 
Jens Axboe

Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

[Christian Brauner]

On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
> On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <brauner@kernel.org> wrote:
> >
> > On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> > > syzbot suspects this issue was fixed by commit:
> > >
> > > commit 6f861765464f43a71462d52026fbddfc858239a5
> > > Author: Jan Kara <jack@suse.cz>
> > > Date:   Wed Nov 1 17:43:10 2023 +0000
> > >
> > >     fs: Block writes to mounted block devices
> > >
> > > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> > > start commit:   2ccdd1b13c59 Linux 6.5-rc6
> > > git tree:       upstream
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> > >
> > > If the result looks correct, please mark the issue as fixed by replying with:
> >
> > #syz fix: fs: Block writes to mounted block devices
> 
> Like Dave replied a few days ago, I'm kind of skeptical on all of these
> bugs being closed by this change. I'm guessing that they are all
> resolved now because a) the block writes while mounted option was set to
> Y, and b) the actual bug is just masked by that.
> 
> Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
> really fixed, and what happens if someone doesn't turn on that option?
> If it's required, perhaps it should not be an option at all? Though
> that'd seem to be likely to break some funky use cases, whether they are
> valid or not.

We have no way of actually testing or verifying this stuff and a lot of
these have been around for a long time. For example, this report here
has a C reproducer but following the actual dashboard link that
reproducer is striked-through which supposedly means that it isn't valid
or reliable. And no other reproducer ever showed up.

As far as I can see we should just close reports such as. If this is a
real bug that is separate from the ability to mount to writed block
devices then one should hope that syzbot finds another reproducer that
let's us really analyze the bug?

A separate issue is that syzbot keeps suggesting as all of these being
closable because of this. So how serious can we take this and how much
time can/should we spend given that we got ~20 or more of these mails in
the last two weeks or so.

I have no better answers than this tbh. And fwiw, apart from this one I
haven't closed a single bug based on this.

And yes, ideally the ability to write to mounted block devices should be
turned off. But we'll have to let it trickle into the individual
distributions first and make remaining userspace tools that rely on this
move to alternate apis before we can make any serious effort.

Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

[Jens Axboe]

On 1/25/24 9:47 AM, Christian Brauner wrote:
> On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
>> On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <brauner@kernel.org> wrote:
>>>
>>> On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
>>>> syzbot suspects this issue was fixed by commit:
>>>>
>>>> commit 6f861765464f43a71462d52026fbddfc858239a5
>>>> Author: Jan Kara <jack@suse.cz>
>>>> Date:   Wed Nov 1 17:43:10 2023 +0000
>>>>
>>>>     fs: Block writes to mounted block devices
>>>>
>>>> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
>>>> start commit:   2ccdd1b13c59 Linux 6.5-rc6
>>>> git tree:       upstream
>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
>>>>
>>>> If the result looks correct, please mark the issue as fixed by replying with:
>>>
>>> #syz fix: fs: Block writes to mounted block devices
>>
>> Like Dave replied a few days ago, I'm kind of skeptical on all of these
>> bugs being closed by this change. I'm guessing that they are all
>> resolved now because a) the block writes while mounted option was set to
>> Y, and b) the actual bug is just masked by that.
>>
>> Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
>> really fixed, and what happens if someone doesn't turn on that option?
>> If it's required, perhaps it should not be an option at all? Though
>> that'd seem to be likely to break some funky use cases, whether they are
>> valid or not.
> 
> We have no way of actually testing or verifying this stuff and a lot of
> these have been around for a long time. For example, this report here
> has a C reproducer but following the actual dashboard link that
> reproducer is striked-through which supposedly means that it isn't valid
> or reliable. And no other reproducer ever showed up.
> 
> As far as I can see we should just close reports such as. If this is a
> real bug that is separate from the ability to mount to writed block
> devices then one should hope that syzbot finds another reproducer that
> let's us really analyze the bug?
> 
> A separate issue is that syzbot keeps suggesting as all of these being
> closable because of this. So how serious can we take this and how much
> time can/should we spend given that we got ~20 or more of these mails in
> the last two weeks or so.
> 
> I have no better answers than this tbh. And fwiw, apart from this one I
> haven't closed a single bug based on this.

Oh yeah, it wasn't directed at you specifically, just the overall class
of bugs that get closed due to this in general.

> And yes, ideally the ability to write to mounted block devices should be
> turned off. But we'll have to let it trickle into the individual
> distributions first and make remaining userspace tools that rely on this
> move to alternate apis before we can make any serious effort.

Hopefully it's all fine on the distro front and we can just make it the
default some years from now. May even make sense to backport some of
this to stable and get it in their hands faster?

-- 
Jens Axboe

Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

[Christian Brauner]

On Thu, Jan 25, 2024 at 09:51:43AM -0700, Jens Axboe wrote:
> On 1/25/24 9:47 AM, Christian Brauner wrote:
> > On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
> >> On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <brauner@kernel.org> wrote:
> >>>
> >>> On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> >>>> syzbot suspects this issue was fixed by commit:
> >>>>
> >>>> commit 6f861765464f43a71462d52026fbddfc858239a5
> >>>> Author: Jan Kara <jack@suse.cz>
> >>>> Date:   Wed Nov 1 17:43:10 2023 +0000
> >>>>
> >>>>     fs: Block writes to mounted block devices
> >>>>
> >>>> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> >>>> start commit:   2ccdd1b13c59 Linux 6.5-rc6
> >>>> git tree:       upstream
> >>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> >>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> >>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> >>>>
> >>>> If the result looks correct, please mark the issue as fixed by replying with:
> >>>
> >>> #syz fix: fs: Block writes to mounted block devices
> >>
> >> Like Dave replied a few days ago, I'm kind of skeptical on all of these
> >> bugs being closed by this change. I'm guessing that they are all
> >> resolved now because a) the block writes while mounted option was set to
> >> Y, and b) the actual bug is just masked by that.
> >>
> >> Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
> >> really fixed, and what happens if someone doesn't turn on that option?
> >> If it's required, perhaps it should not be an option at all? Though
> >> that'd seem to be likely to break some funky use cases, whether they are
> >> valid or not.
> > 
> > We have no way of actually testing or verifying this stuff and a lot of
> > these have been around for a long time. For example, this report here
> > has a C reproducer but following the actual dashboard link that
> > reproducer is striked-through which supposedly means that it isn't valid
> > or reliable. And no other reproducer ever showed up.
> > 
> > As far as I can see we should just close reports such as. If this is a
> > real bug that is separate from the ability to mount to writed block
> > devices then one should hope that syzbot finds another reproducer that
> > let's us really analyze the bug?
> > 
> > A separate issue is that syzbot keeps suggesting as all of these being
> > closable because of this. So how serious can we take this and how much
> > time can/should we spend given that we got ~20 or more of these mails in
> > the last two weeks or so.
> > 
> > I have no better answers than this tbh. And fwiw, apart from this one I
> > haven't closed a single bug based on this.
> 
> Oh yeah, it wasn't directed at you specifically, just the overall class
> of bugs that get closed due to this in general.
> 
> > And yes, ideally the ability to write to mounted block devices should be
> > turned off. But we'll have to let it trickle into the individual
> > distributions first and make remaining userspace tools that rely on this
> > move to alternate apis before we can make any serious effort.
> 
> Hopefully it's all fine on the distro front and we can just make it the
> default some years from now. May even make sense to backport some of
> this to stable and get it in their hands faster?

Yes, I agree that this would be good.

Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

[Aleksandr Nogikh]

On Thu, Jan 25, 2024 at 5:47 PM Christian Brauner <brauner@kernel.org> wrote:
>
> On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
> > On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <brauner@kernel.org> wrote:
> > >
> > > On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> > > > syzbot suspects this issue was fixed by commit:
> > > >
> > > > commit 6f861765464f43a71462d52026fbddfc858239a5
> > > > Author: Jan Kara <jack@suse.cz>
> > > > Date:   Wed Nov 1 17:43:10 2023 +0000
> > > >
> > > >     fs: Block writes to mounted block devices
> > > >
> > > > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> > > > start commit:   2ccdd1b13c59 Linux 6.5-rc6
> > > > git tree:       upstream
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> > > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> > > >
> > > > If the result looks correct, please mark the issue as fixed by replying with:
> > >
> > > #syz fix: fs: Block writes to mounted block devices
> >
> > Like Dave replied a few days ago, I'm kind of skeptical on all of these
> > bugs being closed by this change. I'm guessing that they are all
> > resolved now because a) the block writes while mounted option was set to
> > Y, and b) the actual bug is just masked by that.

Yes, that's true. For a) there are also two sub-reasons:
1) The bug itself is indeed no longer reproducible because of this new
kernel option.
2) The bug is not reproducible because the change broke the way
syzkaller did the mounts -- we used to hold an fd to the loop device
while doing the mount. That was fixed[1] soon after the commit reached
torvalds, but for bisections syzbot has to build syzkaller exactly at
the revision when the reproducer was found (otherwise it may parse the
syz reproducer incorrectly). So this kernel commit becomes exactly the
point where the reproducer stops working.

For most of the recently closed fs bugs (2) should not be the primary
reason though -- these fix bisections are done only when syzbot
stopped seeing crashes with the corresponding titles, which was very
likely caused by (1) in the first place.

[1] https://github.com/google/syzkaller/commit/551587c192ecb4df26fcdab775ed145ee69c07d4

> >
> > Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
> > really fixed, and what happens if someone doesn't turn on that option?
> > If it's required, perhaps it should not be an option at all? Though
> > that'd seem to be likely to break some funky use cases, whether they are
> > valid or not.
>
> We have no way of actually testing or verifying this stuff and a lot of
> these have been around for a long time. For example, this report here
> has a C reproducer but following the actual dashboard link that
> reproducer is striked-through which supposedly means that it isn't valid
> or reliable. And no other reproducer ever showed up.
>
> As far as I can see we should just close reports such as. If this is a
> real bug that is separate from the ability to mount to writed block
> devices then one should hope that syzbot finds another reproducer that
> let's us really analyze the bug?

Yes, if the ability to write to the block device is not really
necessary to trigger the bug, syzbot should find it again in some
time.

>
> A separate issue is that syzbot keeps suggesting as all of these being
> closable because of this. So how serious can we take this and how much
> time can/should we spend given that we got ~20 or more of these mails in
> the last two weeks or so.

I can add the "fs: Block writes to mounted block devices" commit to
the black list for syzbot bisections -- it will stop sending such
emails then.

-- 
Aleksandr

>
> I have no better answers than this tbh. And fwiw, apart from this one I
> haven't closed a single bug based on this.
>
> And yes, ideally the ability to write to mounted block devices should be
> turned off. But we'll have to let it trickle into the individual
> distributions first and make remaining userspace tools that rely on this
> move to alternate apis before we can make any serious effort.
>

Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

[Christian Brauner]

On Thu, Jan 25, 2024 at 07:24:01PM +0100, Aleksandr Nogikh wrote:
> On Thu, Jan 25, 2024 at 5:47 PM Christian Brauner <brauner@kernel.org> wrote:
> >
> > On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
> > > On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <brauner@kernel.org> wrote:
> > > >
> > > > On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> > > > > syzbot suspects this issue was fixed by commit:
> > > > >
> > > > > commit 6f861765464f43a71462d52026fbddfc858239a5
> > > > > Author: Jan Kara <jack@suse.cz>
> > > > > Date:   Wed Nov 1 17:43:10 2023 +0000
> > > > >
> > > > >     fs: Block writes to mounted block devices
> > > > >
> > > > > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> > > > > start commit:   2ccdd1b13c59 Linux 6.5-rc6
> > > > > git tree:       upstream
> > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> > > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> > > > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> > > > >
> > > > > If the result looks correct, please mark the issue as fixed by replying with:
> > > >
> > > > #syz fix: fs: Block writes to mounted block devices
> > >
> > > Like Dave replied a few days ago, I'm kind of skeptical on all of these
> > > bugs being closed by this change. I'm guessing that they are all
> > > resolved now because a) the block writes while mounted option was set to
> > > Y, and b) the actual bug is just masked by that.
> 
> Yes, that's true. For a) there are also two sub-reasons:
> 1) The bug itself is indeed no longer reproducible because of this new
> kernel option.
> 2) The bug is not reproducible because the change broke the way
> syzkaller did the mounts -- we used to hold an fd to the loop device
> while doing the mount. That was fixed[1] soon after the commit reached
> torvalds, but for bisections syzbot has to build syzkaller exactly at
> the revision when the reproducer was found (otherwise it may parse the
> syz reproducer incorrectly). So this kernel commit becomes exactly the
> point where the reproducer stops working.
> 
> For most of the recently closed fs bugs (2) should not be the primary
> reason though -- these fix bisections are done only when syzbot
> stopped seeing crashes with the corresponding titles, which was very
> likely caused by (1) in the first place.
> 
> [1] https://github.com/google/syzkaller/commit/551587c192ecb4df26fcdab775ed145ee69c07d4
> 
> > >
> > > Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
> > > really fixed, and what happens if someone doesn't turn on that option?
> > > If it's required, perhaps it should not be an option at all? Though
> > > that'd seem to be likely to break some funky use cases, whether they are
> > > valid or not.
> >
> > We have no way of actually testing or verifying this stuff and a lot of
> > these have been around for a long time. For example, this report here
> > has a C reproducer but following the actual dashboard link that
> > reproducer is striked-through which supposedly means that it isn't valid
> > or reliable. And no other reproducer ever showed up.
> >
> > As far as I can see we should just close reports such as. If this is a
> > real bug that is separate from the ability to mount to writed block
> > devices then one should hope that syzbot finds another reproducer that
> > let's us really analyze the bug?
> 
> Yes, if the ability to write to the block device is not really
> necessary to trigger the bug, syzbot should find it again in some
> time.
> 
> >
> > A separate issue is that syzbot keeps suggesting as all of these being
> > closable because of this. So how serious can we take this and how much
> > time can/should we spend given that we got ~20 or more of these mails in
> > the last two weeks or so.
> 
> I can add the "fs: Block writes to mounted block devices" commit to
> the black list for syzbot bisections -- it will stop sending such
> emails then.

No, I think it's helpful. I was just saying that we can't be expected to
spend hours per report to check whether this makes sense or not. I
wasn't complaining about this per se.

Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

[syzbot]

Hello,

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

INFO: task syz-executor.2:5688 blocked for more than 143 seconds.
      Not tainted 6.5.0-rc6-syzkaller-dirty #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.2  state:D stack:24584 pid:5688  ppid:5393   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:6845
 rwsem_down_read_slowpath+0x5f4/0x950 kernel/locking/rwsem.c:1086
 __down_read_common kernel/locking/rwsem.c:1250 [inline]
 __down_read kernel/locking/rwsem.c:1263 [inline]
 down_read+0x9c/0x2f0 kernel/locking/rwsem.c:1522
 iterate_supers+0xb0/0x1e0 fs/super.c:742
 quota_sync_all fs/quota/quota.c:69 [inline]
 __do_sys_quotactl fs/quota/quota.c:938 [inline]
 __se_sys_quotactl+0x391/0xa30 fs/quota/quota.c:917
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fb3b1a7cae9
RSP: 002b:00007fb3b28b80c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b3
RAX: ffffffffffffffda RBX: 00007fb3b1b9bf80 RCX: 00007fb3b1a7cae9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff80000101
RBP: 00007fb3b1ac847a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fb3b1b9bf80 R15: 00007fff6eac0208
 </TASK>
INFO: task syz-executor.4:5709 blocked for more than 143 seconds.
      Not tainted 6.5.0-rc6-syzkaller-dirty #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.4  state:D stack:25840 pid:5709  ppid:5390   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:6845
 rwsem_down_write_slowpath+0xedd/0x13a0 kernel/locking/rwsem.c:1178
 __down_write_common+0x1aa/0x200 kernel/locking/rwsem.c:1306
 do_remount fs/namespace.c:2879 [inline]
 path_mount+0xbdd/0xfa0 fs/namespace.c:3654
 do_mount fs/namespace.c:3675 [inline]
 __do_sys_mount fs/namespace.c:3884 [inline]
 __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7efee2a7e1ea
RSP: 002b:00007efee3842ee8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007efee3842f80 RCX: 00007efee2a7e1ea
RDX: 0000000020000180 RSI: 0000000020000100 RDI: 0000000000000000
RBP: 0000000020000180 R08: 00007efee3842f80 R09: 0000000001a404ac
R10: 0000000001a404ac R11: 0000000000000246 R12: 0000000020000100
R13: 00007efee3842f40 R14: 0000000000000000 R15: 0000000020003600
 </TASK>
INFO: task syz-executor.0:5687 blocked for more than 143 seconds.
      Not tainted 6.5.0-rc6-syzkaller-dirty #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.0  state:D stack:24584 pid:5687  ppid:5386   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 jfs_flush_journal+0x733/0xec0 fs/jfs/jfs_logmgr.c:1564
 jfs_sync_fs+0x80/0xa0 fs/jfs/super.c:684
 dquot_quota_sync+0xdb/0x490 fs/quota/dquot.c:704
 iterate_supers+0x12b/0x1e0 fs/super.c:744
 quota_sync_all fs/quota/quota.c:69 [inline]
 __do_sys_quotactl fs/quota/quota.c:938 [inline]
 __se_sys_quotactl+0x391/0xa30 fs/quota/quota.c:917
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fd84a27cae9
RSP: 002b:00007fd84afa50c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b3
RAX: ffffffffffffffda RBX: 00007fd84a39bf80 RCX: 00007fd84a27cae9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff80000101
RBP: 00007fd84a2c847a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fd84a39bf80 R15: 00007ffd56f86288
 </TASK>
INFO: task syz-executor.5:5689 blocked for more than 144 seconds.
      Not tainted 6.5.0-rc6-syzkaller-dirty #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.5  state:D stack:24584 pid:5689  ppid:5387   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:6845
 rwsem_down_read_slowpath+0x5f4/0x950 kernel/locking/rwsem.c:1086
 __down_read_common kernel/locking/rwsem.c:1250 [inline]
 __down_read kernel/locking/rwsem.c:1263 [inline]
 down_read+0x9c/0x2f0 kernel/locking/rwsem.c:1522
 iterate_supers+0xb0/0x1e0 fs/super.c:742
 quota_sync_all fs/quota/quota.c:69 [inline]
 __do_sys_quotactl fs/quota/quota.c:938 [inline]
 __se_sys_quotactl+0x391/0xa30 fs/quota/quota.c:917
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f05ae27cae9
RSP: 002b:00007f05aef3a0c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b3
RAX: ffffffffffffffda RBX: 00007f05ae39bf80 RCX: 00007f05ae27cae9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff80000101
RBP: 00007f05ae2c847a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f05ae39bf80 R15: 00007ffed97249c8
 </TASK>
INFO: task syz-executor.1:5702 blocked for more than 144 seconds.
      Not tainted 6.5.0-rc6-syzkaller-dirty #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.1  state:D stack:24584 pid:5702  ppid:5378   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:6845
 rwsem_down_read_slowpath+0x5f4/0x950 kernel/locking/rwsem.c:1086
 __down_read_common kernel/locking/rwsem.c:1250 [inline]
 __down_read kernel/locking/rwsem.c:1263 [inline]
 down_read+0x9c/0x2f0 kernel/locking/rwsem.c:1522
 iterate_supers+0xb0/0x1e0 fs/super.c:742
 quota_sync_all fs/quota/quota.c:69 [inline]
 __do_sys_quotactl fs/quota/quota.c:938 [inline]
 __se_sys_quotactl+0x391/0xa30 fs/quota/quota.c:917
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f862b87cae9
RSP: 002b:00007f862c6030c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b3
RAX: ffffffffffffffda RBX: 00007f862b99bf80 RCX: 00007f862b87cae9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff80000101
RBP: 00007f862b8c847a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f862b99bf80 R15: 00007ffe1c3a7d68
 </TASK>
INFO: task syz-executor.3:5710 blocked for more than 144 seconds.
      Not tainted 6.5.0-rc6-syzkaller-dirty #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.3  state:D stack:24584 pid:5710  ppid:5382   flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5381 [inline]
 __schedule+0x1873/0x48f0 kernel/sched/core.c:6710
 schedule+0xc3/0x180 kernel/sched/core.c:6786
 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:6845
 rwsem_down_read_slowpath+0x5f4/0x950 kernel/locking/rwsem.c:1086
 __down_read_common kernel/locking/rwsem.c:1250 [inline]
 __down_read kernel/locking/rwsem.c:1263 [inline]
 down_read+0x9c/0x2f0 kernel/locking/rwsem.c:1522
 iterate_supers+0xb0/0x1e0 fs/super.c:742
 quota_sync_all fs/quota/quota.c:69 [inline]
 __do_sys_quotactl fs/quota/quota.c:938 [inline]
 __se_sys_quotactl+0x391/0xa30 fs/quota/quota.c:917
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f626d07cae9
RSP: 002b:00007f626de8d0c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b3
RAX: ffffffffffffffda RBX: 00007f626d19bf80 RCX: 00007f626d07cae9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff80000101
RBP: 00007f626d0c847a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f626d19bf80 R15: 00007ffe891110e8
 </TASK>

Showing all locks held in the system:
1 lock held by rcu_tasks_kthre/13:
 #0: ffffffff8d3295b0 (rcu_tasks.tasks_gp_mutex){+.+.}-{3:3}, at: rcu_tasks_one_gp+0x29/0xd20 kernel/rcu/tasks.h:522
1 lock held by rcu_tasks_trace/14:
 #0: ffffffff8d329970 (rcu_tasks_trace.tasks_gp_mutex){+.+.}-{3:3}, at: rcu_tasks_one_gp+0x29/0xd20 kernel/rcu/tasks.h:522
1 lock held by khungtaskd/28:
 #0: ffffffff8d3293e0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x0/0x30
2 locks held by kworker/u4:2/41:
2 locks held by getty/4770:
 #0: ffff88814bd10098 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
 #1: ffffc900015c02f0 (&ldata->atomic_read_lock){+.+.}-{3:3}, at: n_tty_read+0x6b1/0x1dc0 drivers/tty/n_tty.c:2187
1 lock held by syz-executor.2/5688:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.4/5709:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: do_remount fs/namespace.c:2879 [inline]
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: path_mount+0xbdd/0xfa0 fs/namespace.c:3654
1 lock held by syz-executor.0/5687:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.5/5689:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.1/5702:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.3/5710:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.0/5982:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.2/6002:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.5/6005:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.1/6010:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.4/6012:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.3/6014:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.0/6048:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.2/6104:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.5/6108:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.3/6129:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.1/6131:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742
1 lock held by syz-executor.4/6135:
 #0: ffff8880694560e0 (&type->s_umount_key#64){++++}-{3:3}, at: iterate_supers+0xb0/0x1e0 fs/super.c:742

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

NMI backtrace for cpu 0
CPU: 0 PID: 28 Comm: khungtaskd Not tainted 6.5.0-rc6-syzkaller-dirty #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+0x1e7/0x2d0 lib/dump_stack.c:106
 nmi_cpu_backtrace+0x498/0x4d0 lib/nmi_backtrace.c:113
 nmi_trigger_cpumask_backtrace+0x187/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+0xec2/0xf00 kernel/hung_task.c:379
 kthread+0x2b8/0x350 kernel/kthread.c:389
 ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145
 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
 </TASK>
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 5445 Comm: kworker/1:5 Not tainted 6.5.0-rc6-syzkaller-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
Workqueue: events nsim_dev_trap_report_work
RIP: 0010:on_stack arch/x86/include/asm/stacktrace.h:56 [inline]
RIP: 0010:unwind_next_frame+0x1932/0x2390 arch/x86/kernel/unwind_orc.c:665
Code: 89 f8 48 c1 e8 03 80 3c 18 00 74 05 e8 17 e6 a7 00 4c 8b 75 08 48 8d 5d 10 48 89 d8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 48 89 df e8 f0 e5 a7 00 4d 39 fe 0f 87 ba 00 00
RSP: 0018:ffffc90005ae7610 EFLAGS: 00000a06
RAX: 1ffff92000b5cede RBX: ffffc90005ae76f0 RCX: dffffc0000000000
RDX: dffffc0000000000 RSI: ffffc90005ae0000 RDI: ffffc90005ae76e8
RBP: ffffc90005ae76e0 R08: ffffc90005ae7850 R09: 0000000000000000
R10: ffffc90005ae7730 R11: fffff52000b5cee8 R12: 1ffffffff1e31b57
R13: 1ffff92000b5cedd R14: ffffc90005ae0000 R15: ffffc90005ae7860
FS:  0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555d7f21b030 CR3: 000000002c0f7000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <NMI>
 </NMI>
 <TASK>
 arch_stack_walk+0x111/0x140 arch/x86/kernel/stacktrace.c:25
 stack_trace_save+0x117/0x1c0 kernel/stacktrace.c:122
 kasan_save_stack mm/kasan/common.c:45 [inline]
 kasan_set_track+0x4f/0x70 mm/kasan/common.c:52
 kasan_save_free_info+0x28/0x40 mm/kasan/generic.c:522
 ____kasan_slab_free+0xd6/0x120 mm/kasan/common.c:236
 kasan_slab_free include/linux/kasan.h:162 [inline]
 slab_free_hook mm/slub.c:1792 [inline]
 slab_free_freelist_hook mm/slub.c:1818 [inline]
 slab_free mm/slub.c:3801 [inline]
 kmem_cache_free+0x292/0x500 mm/slub.c:3823
 nsim_dev_trap_report drivers/net/netdevsim/dev.c:821 [inline]
 nsim_dev_trap_report_work+0x761/0xa90 drivers/net/netdevsim/dev.c:850
 process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600
 worker_thread+0xa63/0x1210 kernel/workqueue.c:2751
 kthread+0x2b8/0x350 kernel/kthread.c:389
 ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145
 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
 </TASK>


Tested on:

commit:         2ccdd1b1 Linux 6.5-rc6
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=10ba0ebba80000
kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=16856a4ba80000