linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [syzbot] [fs?] INFO: task hung in vfs_rename (2)
@ 2025-04-22 21:28 syzbot
  2025-04-23 11:35 ` Jan Kara
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: syzbot @ 2025-04-22 21:28 UTC (permalink / raw)
  To: brauner, jack, linux-fsdevel, linux-kernel, syzkaller-bugs, viro

Hello,

syzbot found the following issue on:

HEAD commit:    fc96b232f8e7 Merge tag 'pci-v6.15-fixes-2' of git://git.ke..
git tree:       upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=10c65fe4580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=170d968a88ba5c06
dashboard link: https://syzkaller.appspot.com/bug?extid=321477fad98ea6dd35b7
compiler:       Debian clang version 15.0.6, Debian LLD 15.0.6
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11075470580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13a6063f980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/fd977d7e57de/disk-fc96b232.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ffa0a3b5b655/vmlinux-fc96b232.xz
kernel image: https://storage.googleapis.com/syzbot-assets/44df3bd100d2/bzImage-fc96b232.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/b166f1d5e115/mount_0.gz
  fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=12655204580000)

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

INFO: task syz-executor362:5849 blocked for more than 143 seconds.
      Not tainted 6.15.0-rc2-syzkaller-00278-gfc96b232f8e7 #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor362 state:D stack:24280 pid:5849  tgid:5849  ppid:5848   task_flags:0x400140 flags:0x00004006
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5382 [inline]
 __schedule+0x1b33/0x51f0 kernel/sched/core.c:6767
 __schedule_loop kernel/sched/core.c:6845 [inline]
 schedule+0x163/0x360 kernel/sched/core.c:6860
 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6917
 rwsem_down_write_slowpath+0xedd/0x1420 kernel/locking/rwsem.c:1176
 __down_write_common kernel/locking/rwsem.c:1304 [inline]
 __down_write kernel/locking/rwsem.c:1313 [inline]
 down_write+0x1da/0x220 kernel/locking/rwsem.c:1578
 inode_lock include/linux/fs.h:867 [inline]
 vfs_rename+0x6b9/0xf10 fs/namei.c:5051
 do_renameat2+0xc8d/0x1290 fs/namei.c:5235
 __do_sys_renameat2 fs/namei.c:5269 [inline]
 __se_sys_renameat2 fs/namei.c:5266 [inline]
 __x64_sys_renameat2+0xce/0xe0 fs/namei.c:5266
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xf3/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fc3678ce519
RSP: 002b:00007ffc519cacb8 EFLAGS: 00000246 ORIG_RAX: 000000000000013c
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc3678ce519
RDX: 0000000000000004 RSI: 0000200000000240 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000000 R09: 00007ffc519cacf0
R10: 00002000000001c0 R11: 0000000000000246 R12: 00007ffc519cacf0
R13: 00007ffc519caf78 R14: 431bde82d7b634db R15: 00007fc36791703b
 </TASK>

Showing all locks held in the system:
1 lock held by khungtaskd/31:
 #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
 #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
 #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x30/0x180 kernel/locking/lockdep.c:6764
2 locks held by getty/5587:
 #0: ffff8880366f20a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
 #1: ffffc900036d62f0 (&ldata->atomic_read_lock){+.+.}-{4:4}, at: n_tty_read+0x5bb/0x1700 drivers/tty/n_tty.c:2222
6 locks held by syz-executor362/5849:
 #0: ffff88807f054420 (sb_writers#8){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88807f054730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3234 [inline]
 #1: ffff88807f054730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5d6/0x1290 fs/namei.c:5181
 #2: ffff88807b3e8910 (&sb->s_type->i_mutex_key#14/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff88807b3e8910 (&sb->s_type->i_mutex_key#14/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3210
 #3: ffff88807b2b8910 (&sb->s_type->i_mutex_key#14/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff88807b2b8910 (&sb->s_type->i_mutex_key#14/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3211
 #4: ffff88807b2b82a0 (&sb->s_type->i_mutex_key#14/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff88807b2b82a0 (&sb->s_type->i_mutex_key#14/2){+.+.}-{4:4}, at: vfs_rename+0x63f/0xf10 fs/namei.c:5049
 #5: ffff88807b2b8910 (&sb->s_type->i_mutex_key#14){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff88807b2b8910 (&sb->s_type->i_mutex_key#14){++++}-{4:4}, at: vfs_rename+0x6b9/0xf10 fs/namei.c:5051

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

NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 31 Comm: khungtaskd Not tainted 6.15.0-rc2-syzkaller-00278-gfc96b232f8e7 #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 nmi_cpu_backtrace+0x4ab/0x4e0 lib/nmi_backtrace.c:113
 nmi_trigger_cpumask_backtrace+0x198/0x320 lib/nmi_backtrace.c:62
 trigger_all_cpu_backtrace include/linux/nmi.h:158 [inline]
 check_hung_uninterruptible_tasks kernel/hung_task.c:274 [inline]
 watchdog+0x1058/0x10a0 kernel/hung_task.c:437
 kthread+0x7b7/0x940 kernel/kthread.c:464
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:153
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.15.0-rc2-syzkaller-00278-gfc96b232f8e7 #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
RIP: 0010:pv_native_safe_halt+0x13/0x20 arch/x86/kernel/paravirt.c:81
Code: cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 73 5f 20 00 f3 0f 1e fa fb f4 <c3> cc cc cc cc cc cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffffff8ea07d60 EFLAGS: 000002c2
RAX: 5fa1c341e9d1cd00 RBX: ffffffff8197267e RCX: ffffffff8c27d93c
RDX: 0000000000000001 RSI: ffffffff8e6356dd RDI: ffffffff8ca0e2e0
RBP: ffffffff8ea07eb8 R08: ffff8880b8632b5b R09: 1ffff110170c656b
R10: dffffc0000000000 R11: ffffed10170c656c R12: 1ffffffff1d40fc6
R13: 1ffffffff1d52cb0 R14: 0000000000000000 R15: dffffc0000000000
FS:  0000000000000000(0000) GS:ffff888124fcf000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005597c9480600 CR3: 000000000eb38000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 arch_safe_halt arch/x86/include/asm/paravirt.h:107 [inline]
 default_idle+0x13/0x20 arch/x86/kernel/process.c:748
 default_idle_call+0x74/0xb0 kernel/sched/idle.c:117
 cpuidle_idle_call kernel/sched/idle.c:185 [inline]
 do_idle+0x22e/0x5d0 kernel/sched/idle.c:325
 cpu_startup_entry+0x42/0x60 kernel/sched/idle.c:423
 rest_init+0x2dc/0x300 init/main.c:743
 start_kernel+0x484/0x510 init/main.c:1099
 x86_64_start_reservations+0x2a/0x30 arch/x86/kernel/head64.c:513
 x86_64_start_kernel+0x66/0x70 arch/x86/kernel/head64.c:494
 common_startup_64+0x13e/0x147
 </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 report is already addressed, 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 report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [syzbot] [fs?] INFO: task hung in vfs_rename (2)
  2025-04-22 21:28 [syzbot] [fs?] INFO: task hung in vfs_rename (2) syzbot
@ 2025-04-23 11:35 ` Jan Kara
  2025-05-13 12:00 ` Edward Adam Davis
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 13+ messages in thread
From: Jan Kara @ 2025-04-23 11:35 UTC (permalink / raw)
  To: syzbot
  Cc: brauner, jack, linux-fsdevel, linux-kernel, syzkaller-bugs, viro,
	Miklos Szeredi

On Tue 22-04-25 14:28:19, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    fc96b232f8e7 Merge tag 'pci-v6.15-fixes-2' of git://git.ke..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=10c65fe4580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=170d968a88ba5c06
> dashboard link: https://syzkaller.appspot.com/bug?extid=321477fad98ea6dd35b7
> compiler:       Debian clang version 15.0.6, Debian LLD 15.0.6
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11075470580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13a6063f980000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/fd977d7e57de/disk-fc96b232.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/ffa0a3b5b655/vmlinux-fc96b232.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/44df3bd100d2/bzImage-fc96b232.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/b166f1d5e115/mount_0.gz
>   fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=12655204580000)
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+321477fad98ea6dd35b7@syzkaller.appspotmail.com
> 
> INFO: task syz-executor362:5849 blocked for more than 143 seconds.
>       Not tainted 6.15.0-rc2-syzkaller-00278-gfc96b232f8e7 #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:syz-executor362 state:D stack:24280 pid:5849  tgid:5849  ppid:5848   task_flags:0x400140 flags:0x00004006
> Call Trace:
>  <TASK>
>  context_switch kernel/sched/core.c:5382 [inline]
>  __schedule+0x1b33/0x51f0 kernel/sched/core.c:6767
>  __schedule_loop kernel/sched/core.c:6845 [inline]
>  schedule+0x163/0x360 kernel/sched/core.c:6860
>  schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6917
>  rwsem_down_write_slowpath+0xedd/0x1420 kernel/locking/rwsem.c:1176
>  __down_write_common kernel/locking/rwsem.c:1304 [inline]
>  __down_write kernel/locking/rwsem.c:1313 [inline]
>  down_write+0x1da/0x220 kernel/locking/rwsem.c:1578
>  inode_lock include/linux/fs.h:867 [inline]
>  vfs_rename+0x6b9/0xf10 fs/namei.c:5051
>  do_renameat2+0xc8d/0x1290 fs/namei.c:5235
>  __do_sys_renameat2 fs/namei.c:5269 [inline]
>  __se_sys_renameat2 fs/namei.c:5266 [inline]
>  __x64_sys_renameat2+0xce/0xe0 fs/namei.c:5266
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xf3/0x210 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f

The hang happens at:

inode_lock(target);

in vfs_rename() where 'target' is 'file0' which is a mountpoint of a FUSE
filesystem. Miklos?

								Honza

> RIP: 0033:0x7fc3678ce519
> RSP: 002b:00007ffc519cacb8 EFLAGS: 00000246 ORIG_RAX: 000000000000013c
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc3678ce519
> RDX: 0000000000000004 RSI: 0000200000000240 RDI: 0000000000000004
> RBP: 0000000000000000 R08: 0000000000000000 R09: 00007ffc519cacf0
> R10: 00002000000001c0 R11: 0000000000000246 R12: 00007ffc519cacf0
> R13: 00007ffc519caf78 R14: 431bde82d7b634db R15: 00007fc36791703b
>  </TASK>
> 
> Showing all locks held in the system:
> 1 lock held by khungtaskd/31:
>  #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
>  #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
>  #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x30/0x180 kernel/locking/lockdep.c:6764
> 2 locks held by getty/5587:
>  #0: ffff8880366f20a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
>  #1: ffffc900036d62f0 (&ldata->atomic_read_lock){+.+.}-{4:4}, at: n_tty_read+0x5bb/0x1700 drivers/tty/n_tty.c:2222
> 6 locks held by syz-executor362/5849:
>  #0: ffff88807f054420 (sb_writers#8){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
>  #1: ffff88807f054730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3234 [inline]
>  #1: ffff88807f054730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5d6/0x1290 fs/namei.c:5181
>  #2: ffff88807b3e8910 (&sb->s_type->i_mutex_key#14/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
>  #2: ffff88807b3e8910 (&sb->s_type->i_mutex_key#14/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3210
>  #3: ffff88807b2b8910 (&sb->s_type->i_mutex_key#14/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
>  #3: ffff88807b2b8910 (&sb->s_type->i_mutex_key#14/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3211
>  #4: ffff88807b2b82a0 (&sb->s_type->i_mutex_key#14/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
>  #4: ffff88807b2b82a0 (&sb->s_type->i_mutex_key#14/2){+.+.}-{4:4}, at: vfs_rename+0x63f/0xf10 fs/namei.c:5049
>  #5: ffff88807b2b8910 (&sb->s_type->i_mutex_key#14){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
>  #5: ffff88807b2b8910 (&sb->s_type->i_mutex_key#14){++++}-{4:4}, at: vfs_rename+0x6b9/0xf10 fs/namei.c:5051
> 
> =============================================
> 
> NMI backtrace for cpu 1
> CPU: 1 UID: 0 PID: 31 Comm: khungtaskd Not tainted 6.15.0-rc2-syzkaller-00278-gfc96b232f8e7 #0 PREEMPT(full) 
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:94 [inline]
>  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
>  nmi_cpu_backtrace+0x4ab/0x4e0 lib/nmi_backtrace.c:113
>  nmi_trigger_cpumask_backtrace+0x198/0x320 lib/nmi_backtrace.c:62
>  trigger_all_cpu_backtrace include/linux/nmi.h:158 [inline]
>  check_hung_uninterruptible_tasks kernel/hung_task.c:274 [inline]
>  watchdog+0x1058/0x10a0 kernel/hung_task.c:437
>  kthread+0x7b7/0x940 kernel/kthread.c:464
>  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:153
>  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>  </TASK>
> Sending NMI from CPU 1 to CPUs 0:
> NMI backtrace for cpu 0
> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.15.0-rc2-syzkaller-00278-gfc96b232f8e7 #0 PREEMPT(full) 
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
> RIP: 0010:pv_native_safe_halt+0x13/0x20 arch/x86/kernel/paravirt.c:81
> Code: cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 73 5f 20 00 f3 0f 1e fa fb f4 <c3> cc cc cc cc cc cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90
> RSP: 0018:ffffffff8ea07d60 EFLAGS: 000002c2
> RAX: 5fa1c341e9d1cd00 RBX: ffffffff8197267e RCX: ffffffff8c27d93c
> RDX: 0000000000000001 RSI: ffffffff8e6356dd RDI: ffffffff8ca0e2e0
> RBP: ffffffff8ea07eb8 R08: ffff8880b8632b5b R09: 1ffff110170c656b
> R10: dffffc0000000000 R11: ffffed10170c656c R12: 1ffffffff1d40fc6
> R13: 1ffffffff1d52cb0 R14: 0000000000000000 R15: dffffc0000000000
> FS:  0000000000000000(0000) GS:ffff888124fcf000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005597c9480600 CR3: 000000000eb38000 CR4: 00000000003526f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  <TASK>
>  arch_safe_halt arch/x86/include/asm/paravirt.h:107 [inline]
>  default_idle+0x13/0x20 arch/x86/kernel/process.c:748
>  default_idle_call+0x74/0xb0 kernel/sched/idle.c:117
>  cpuidle_idle_call kernel/sched/idle.c:185 [inline]
>  do_idle+0x22e/0x5d0 kernel/sched/idle.c:325
>  cpu_startup_entry+0x42/0x60 kernel/sched/idle.c:423
>  rest_init+0x2dc/0x300 init/main.c:743
>  start_kernel+0x484/0x510 init/main.c:1099
>  x86_64_start_reservations+0x2a/0x30 arch/x86/kernel/head64.c:513
>  x86_64_start_kernel+0x66/0x70 arch/x86/kernel/head64.c:494
>  common_startup_64+0x13e/0x147
>  </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 report is already addressed, 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 report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
> 
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
> 
> If you want to undo deduplication, reply with:
> #syz undup
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [syzbot] [fs?] INFO: task hung in vfs_rename (2)
       [not found] <20250423110503.4262-1-hdanton@sina.com>
@ 2025-04-23 18:39 ` syzbot
  0 siblings, 0 replies; 13+ messages in thread
From: syzbot @ 2025-04-23 18:39 UTC (permalink / raw)
  To: hdanton, linux-kernel, syzkaller-bugs

Hello,

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

INFO: task syz.0.16:6726 blocked for more than 143 seconds.
      Not tainted 6.15.0-rc3-syzkaller-00032-ga79be02bba5c-dirty #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.0.16        state:D stack:24200 pid:6726  tgid:6725  ppid:6628   task_flags:0x400140 flags:0x00004004
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5382 [inline]
 __schedule+0x1b33/0x51f0 kernel/sched/core.c:6767
 __schedule_loop kernel/sched/core.c:6845 [inline]
 schedule+0x163/0x360 kernel/sched/core.c:6860
 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6917
 rwsem_down_write_slowpath+0xedd/0x1420 kernel/locking/rwsem.c:1176
 __down_write_common kernel/locking/rwsem.c:1304 [inline]
 __down_write kernel/locking/rwsem.c:1313 [inline]
 down_write+0x1da/0x220 kernel/locking/rwsem.c:1578
 inode_lock include/linux/fs.h:867 [inline]
 vfs_rename+0x6ba/0xf10 fs/namei.c:5088
 do_renameat2+0xdbc/0x1410 fs/namei.c:5272
 __do_sys_renameat2 fs/namei.c:5306 [inline]
 __se_sys_renameat2 fs/namei.c:5303 [inline]
 __x64_sys_renameat2+0xce/0xe0 fs/namei.c:5303
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xf3/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2a8618e169
RSP: 002b:00007f2a86fb8038 EFLAGS: 00000246 ORIG_RAX: 000000000000013c
RAX: ffffffffffffffda RBX: 00007f2a863b5fa0 RCX: 00007f2a8618e169
RDX: 0000000000000004 RSI: 0000200000000240 RDI: 0000000000000004
RBP: 00007f2a86210a68 R08: 0000000000000000 R09: 0000000000000000
R10: 00002000000001c0 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f2a863b5fa0 R15: 00007ffe0a55d7f8
 </TASK>

Showing all locks held in the system:
1 lock held by khungtaskd/31:
 #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
 #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
 #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x30/0x180 kernel/locking/lockdep.c:6764
2 locks held by klogd/5191:
 #0: ffff8880b8739998 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2a/0x140 kernel/sched/core.c:605
 #1: ffffffff8ee55700 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: local_lock_acquire include/linux/local_lock_internal.h:38 [inline]
 #1: ffffffff8ee55700 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: put_cpu_partial+0x72/0x250 mm/slub.c:3246
2 locks held by getty/5581:
 #0: ffff888035d420a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
 #1: ffffc9000332e2f0 (&ldata->atomic_read_lock){+.+.}-{4:4}, at: n_tty_read+0x5bb/0x1700 drivers/tty/n_tty.c:2222
6 locks held by syz.0.16/6726:
 #0: ffff88802578e420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88802578e730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff88802578e730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5f6/0x1410 fs/namei.c:5218
 #2: ffff888074f88910 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888074f88910 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff888074ed15f0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff888074ed15f0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888074ed02a0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888074ed02a0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x644/0xf10 fs/namei.c:5086
 #5: ffff888074ed15f0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff888074ed15f0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6ba/0xf10 fs/namei.c:5088
6 locks held by syz.1.17/6779:
 #0: ffff88807cc5e420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88807cc5e730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff88807cc5e730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5f6/0x1410 fs/namei.c:5218
 #2: ffff888074f895f0 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888074f895f0 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff888074f8afb0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff888074f8afb0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888074f89c60 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888074f89c60 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x644/0xf10 fs/namei.c:5086
 #5: ffff888074f8afb0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff888074f8afb0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6ba/0xf10 fs/namei.c:5088
6 locks held by syz.2.18/6796:
 #0: ffff88802fa2e420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88802fa2e730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff88802fa2e730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5f6/0x1410 fs/namei.c:5218
 #2: ffff888074f8b620 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888074f8b620 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff888074f8cfe0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff888074f8cfe0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888074f8bc90 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888074f8bc90 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x644/0xf10 fs/namei.c:5086
 #5: ffff888074f8cfe0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff888074f8cfe0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6ba/0xf10 fs/namei.c:5088
6 locks held by syz.3.19/6813:
 #0: ffff888012f68420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff888012f68730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff888012f68730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5f6/0x1410 fs/namei.c:5218
 #2: ffff888074ed2940 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888074ed2940 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff888074ed4300 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff888074ed4300 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888074ed2fb0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888074ed2fb0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x644/0xf10 fs/namei.c:5086
 #5: ffff888074ed4300 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff888074ed4300 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6ba/0xf10 fs/namei.c:5088
6 locks held by syz.4.20/6837:
 #0: ffff88807df2c420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88807df2c730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff88807df2c730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5f6/0x1410 fs/namei.c:5218
 #2: ffff888074ed4970 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888074ed4970 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff888074f8f010 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff888074f8f010 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888074f8dcc0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888074f8dcc0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x644/0xf10 fs/namei.c:5086
 #5: ffff888074f8f010 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff888074f8f010 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6ba/0xf10 fs/namei.c:5088
6 locks held by syz.5.21/6860:
 #0: ffff88805d98a420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88805d98a730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff88805d98a730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5f6/0x1410 fs/namei.c:5218
 #2: ffff888074ed5650 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888074ed5650 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff88805b0b0f80 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff88805b0b0f80 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888074f8f680 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888074f8f680 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x644/0xf10 fs/namei.c:5086
 #5: ffff88805b0b0f80 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff88805b0b0f80 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6ba/0xf10 fs/namei.c:5088
6 locks held by syz.6.22/6883:
 #0: 
ffff8880133c0420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff8880133c0730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff8880133c0730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5f6/0x1410 fs/namei.c:5218
 #2: ffff888074ed6330 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888074ed6330 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff88805b0682a0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff88805b0682a0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888074ed69a0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888074ed69a0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x644/0xf10 fs/namei.c:5086
 #5: ffff88805b0682a0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff88805b0682a0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6ba/0xf10 fs/namei.c:5088
6 locks held by syz.7.23/6912:
 #0: ffff888079842420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff888079842730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff888079842730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5f6/0x1410 fs/namei.c:5218
 #2: ffff88805b0b1c60 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff88805b0b1c60 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff88805b0695f0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff88805b0695f0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff88805b0b22d0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff88805b0b22d0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x644/0xf10 fs/namei.c:5086
 #5: ffff88805b0695f0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff88805b0695f0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6ba/0xf10 fs/namei.c:5088
6 locks held by syz.8.24/6938:
 #0: ffff88814d47a420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88814d47a730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff88814d47a730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5f6/0x1410 fs/namei.c:5218
 #2: ffff88805b069c60 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff88805b069c60 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff88805b06afb0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff88805b06afb0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff88805b0b2fb0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff88805b0b2fb0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x644/0xf10 fs/namei.c:5086
 #5: ffff88805b06afb0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff88805b06afb0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6ba/0xf10 fs/namei.c:5088
4 locks held by syz-executor/6941:

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

NMI backtrace for cpu 0
CPU: 0 UID: 0 PID: 31 Comm: khungtaskd Not tainted 6.15.0-rc3-syzkaller-00032-ga79be02bba5c-dirty #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 nmi_cpu_backtrace+0x4ab/0x4e0 lib/nmi_backtrace.c:113
 nmi_trigger_cpumask_backtrace+0x198/0x320 lib/nmi_backtrace.c:62
 trigger_all_cpu_backtrace include/linux/nmi.h:158 [inline]
 check_hung_uninterruptible_tasks kernel/hung_task.c:274 [inline]
 watchdog+0x1058/0x10a0 kernel/hung_task.c:437
 kthread+0x7b7/0x940 kernel/kthread.c:464
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:153
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 6941 Comm: syz-executor Not tainted 6.15.0-rc3-syzkaller-00032-ga79be02bba5c-dirty #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
RIP: 0010:io_serial_in+0x76/0xb0 drivers/tty/serial/8250/8250_port.c:409
Code: c0 f6 33 fc 89 e9 41 d3 e6 48 83 c3 40 48 89 d8 48 c1 e8 03 42 80 3c 38 00 74 08 48 89 df e8 81 9f 9b fc 44 03 33 44 89 f2 ec <0f> b6 c0 5b 41 5e 41 5f 5d c3 cc cc cc cc 89 e9 80 e1 07 38 c1 7c
RSP: 0018:ffffc90003e9e998 EFLAGS: 00000006
RAX: 1ffffffff3548f05 RBX: ffffffff9aa47960 RCX: 0000000000000000
RDX: 00000000000003f9 RSI: 0000000000000000 RDI: 0000000000000020
RBP: 0000000000000000 R08: ffffffff858ec596 R09: fffff520007d3d14
R10: dffffc0000000000 R11: ffffffff858ec550 R12: 0000000000000000
R13: dffffc0000000000 R14: 00000000000003f9 R15: dffffc0000000000
FS:  0000555587553500(0000) GS:ffff8881250cf000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe8470e7d60 CR3: 0000000034592000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 serial_port_in include/linux/serial_core.h:791 [inline]
 serial8250_console_write+0x4c0/0x1e00 drivers/tty/serial/8250/8250_port.c:3420
 console_emit_next_record kernel/printk/printk.c:3138 [inline]
 console_flush_all+0x86b/0xec0 kernel/printk/printk.c:3226
 __console_flush_and_unlock kernel/printk/printk.c:3285 [inline]
 console_unlock+0x151/0x3b0 kernel/printk/printk.c:3325
 vprintk_emit+0x761/0xa40 kernel/printk/printk.c:2450
 _printk+0xd5/0x120 kernel/printk/printk.c:2475
 caif_netlink_parms net/caif/chnl_net.c:424 [inline]
 ipcaif_newlink+0x201/0x4f0 net/caif/chnl_net.c:450
 rtnl_newlink_create+0x39b/0xcb0 net/core/rtnetlink.c:3833
 __rtnl_newlink net/core/rtnetlink.c:3950 [inline]
 rtnl_newlink+0x18b0/0x1fe0 net/core/rtnetlink.c:4065
 rtnetlink_rcv_msg+0x80f/0xd70 net/core/rtnetlink.c:6955
 netlink_rcv_skb+0x208/0x480 net/netlink/af_netlink.c:2534
 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
 netlink_unicast+0x7f8/0x9a0 net/netlink/af_netlink.c:1339
 netlink_sendmsg+0x8c3/0xcd0 net/netlink/af_netlink.c:1883
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg+0x221/0x270 net/socket.c:727
 __sys_sendto+0x365/0x4c0 net/socket.c:2180
 __do_sys_sendto net/socket.c:2187 [inline]
 __se_sys_sendto net/socket.c:2183 [inline]
 __x64_sys_sendto+0xde/0x100 net/socket.c:2183
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xf3/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe84638fffc
Code: 2a 5f 02 00 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 70 5f 02 00 48 8b
RSP: 002b:00007ffd204ef3a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007fe8470e4620 RCX: 00007fe84638fffc
RDX: 0000000000000038 RSI: 00007fe8470e4670 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00007ffd204ef3f4 R09: 000000000000000c
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000003
R13: 0000000000000000 R14: 00007fe8470e4670 R15: 0000000000000000
 </TASK>


Tested on:

commit:         a79be02b Fix mis-uses of 'cc-option' for warning disab..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1057ba6f980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=3bbffc3b5b4301e1
dashboard link: https://syzkaller.appspot.com/bug?extid=321477fad98ea6dd35b7
compiler:       Debian clang version 15.0.6, Debian LLD 15.0.6
patch:          https://syzkaller.appspot.com/x/patch.diff?x=166c9f54580000


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [syzbot] [fs?] INFO: task hung in vfs_rename (2)
       [not found] <20250424110546.4284-1-hdanton@sina.com>
@ 2025-04-24 12:01 ` syzbot
  2025-04-24 19:51   ` Al Viro
  0 siblings, 1 reply; 13+ messages in thread
From: syzbot @ 2025-04-24 12:01 UTC (permalink / raw)
  To: hdanton, linux-kernel, syzkaller-bugs

Hello,

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

INFO: task syz.0.16:6758 blocked for more than 143 seconds.
      Not tainted 6.15.0-rc3-syzkaller-00032-ga79be02bba5c-dirty #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.0.16        state:D stack:24088 pid:6758  tgid:6757  ppid:6641   task_flags:0x400140 flags:0x00004004
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5382 [inline]
 __schedule+0x1b33/0x51f0 kernel/sched/core.c:6767
 __schedule_loop kernel/sched/core.c:6845 [inline]
 schedule+0x163/0x360 kernel/sched/core.c:6860
 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6917
 rwsem_down_write_slowpath+0xedd/0x1420 kernel/locking/rwsem.c:1176
 __down_write_common kernel/locking/rwsem.c:1304 [inline]
 __down_write kernel/locking/rwsem.c:1313 [inline]
 down_write+0x1da/0x220 kernel/locking/rwsem.c:1578
 inode_lock include/linux/fs.h:867 [inline]
 vfs_rename+0x6b9/0xf10 fs/namei.c:5086
 do_renameat2+0x106c/0x1440 fs/namei.c:5272
 __do_sys_renameat2 fs/namei.c:5306 [inline]
 __se_sys_renameat2 fs/namei.c:5303 [inline]
 __x64_sys_renameat2+0xce/0xe0 fs/namei.c:5303
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xf3/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f85e2b8e169
RSP: 002b:00007f85e3ac8038 EFLAGS: 00000246 ORIG_RAX: 000000000000013c
RAX: ffffffffffffffda RBX: 00007f85e2db5fa0 RCX: 00007f85e2b8e169
RDX: 0000000000000004 RSI: 0000200000000240 RDI: 0000000000000004
RBP: 00007f85e2c10a68 R08: 0000000000000000 R09: 0000000000000000
R10: 00002000000001c0 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f85e2db5fa0 R15: 00007fffcd12b258
 </TASK>

Showing all locks held in the system:
1 lock held by khungtaskd/31:
 #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
 #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
 #0: ffffffff8ed3df20 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x30/0x180 kernel/locking/lockdep.c:6764
2 locks held by kworker/u8:3/47:
 #0: ffff8880b8739998 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2a/0x140 kernel/sched/core.c:605
 #1: ffff8880b8723b08 (&per_cpu_ptr(group->pcpu, cpu)->seq){-.-.}-{0:0}, at: psi_task_switch+0x389/0x7a0 kernel/sched/psi.c:975
2 locks held by getty/5593:
 #0: ffff888035d2a0a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
 #1: ffffc900036db2f0 (&ldata->atomic_read_lock){+.+.}-{4:4}, at: n_tty_read+0x5bb/0x1700 drivers/tty/n_tty.c:2222
6 locks held by syz.0.16/6758:
 #0: ffff888024c56420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff888024c56730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff888024c56730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5ea/0x1440 fs/namei.c:5216
 #2: ffff888070bc8910 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888070bc8910 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff8880709c15f0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff8880709c15f0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff8880709c02a0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff8880709c02a0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x63f/0xf10 fs/namei.c:5084
 #5: ffff8880709c15f0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff8880709c15f0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6b9/0xf10 fs/namei.c:5086
6 locks held by syz.1.17/6888:
 #0: ffff88802e1aa420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88802e1aa730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff88802e1aa730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5ea/0x1440 fs/namei.c:5216
 #2: ffff888070bc95f0 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888070bc95f0 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff888070bcafb0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff888070bcafb0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888070bc9c60 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888070bc9c60 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x63f/0xf10 fs/namei.c:5084
 #5: ffff888070bcafb0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff888070bcafb0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6b9/0xf10 fs/namei.c:5086
6 locks held by syz.2.18/6905:
 #0: ffff88807dcc0420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88807dcc0730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff88807dcc0730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5ea/0x1440 fs/namei.c:5216
 #2: ffff8880709c22d0 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff8880709c22d0 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff8880709c3c90 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff8880709c3c90 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff8880709c2940 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff8880709c2940 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x63f/0xf10 fs/namei.c:5084
 #5: ffff8880709c3c90 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff8880709c3c90 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6b9/0xf10 fs/namei.c:5086
6 locks held by syz.3.19/6922:
 #0: ffff88807e762420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88807e762730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff88807e762730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5ea/0x1440 fs/namei.c:5216
 #2: ffff888070bcbc90 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888070bcbc90 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff888070bcd650 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff888070bcd650 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888070bcc300 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888070bcc300 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x63f/0xf10 fs/namei.c:5084
 #5: ffff888070bcd650 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff888070bcd650 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6b9/0xf10 fs/namei.c:5086
6 locks held by syz.4.20/6945:
 #0: ffff88807d390420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88807d390730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff88807d390730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5ea/0x1440 fs/namei.c:5216
 #2: ffff888070bce330 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888070bce330 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff888070be82a0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff888070be82a0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888070bce9a0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888070bce9a0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x63f/0xf10 fs/namei.c:5084
 #5: ffff888070be82a0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff888070be82a0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6b9/0xf10 fs/namei.c:5086
6 locks held by syz.5.21/6968:
 #0: ffff888073312420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff888073312730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff888073312730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5ea/0x1440 fs/namei.c:5216
 #2: ffff8880709c4970 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff8880709c4970 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff888070be8f80 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff888070be8f80 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff8880709c4fe0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff8880709c4fe0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x63f/0xf10 fs/namei.c:5084
 #5: ffff888070be8f80 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff888070be8f80 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6b9/0xf10 fs/namei.c:5086
6 locks held by syz.6.22/6991:
 #0: ffff88807d4ce420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff88807d4ce730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff88807d4ce730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5ea/0x1440 fs/namei.c:5216
 #2: ffff888070be95f0 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888070be95f0 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff888070beafb0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff888070beafb0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888070be9c60 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888070be9c60 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x63f/0xf10 fs/namei.c:5084
 #5: ffff888070beafb0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff888070beafb0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6b9/0xf10 fs/namei.c:5086
6 locks held by syz.7.23/7020:
 #0: ffff888035186420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff888035186730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff888035186730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5ea/0x1440 fs/namei.c:5216
 #2: ffff888070bebc90 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888070bebc90 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff888070bed650 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff888070bed650 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888070bec300 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888070bec300 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x63f/0xf10 fs/namei.c:5084
 #5: ffff888070bed650 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff888070bed650 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6b9/0xf10 fs/namei.c:5086
6 locks held by syz.8.24/7045:
 #0: ffff888142fa6420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:556
 #1: ffff888142fa6730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: lock_rename fs/namei.c:3269 [inline]
 #1: ffff888142fa6730 (&type->s_vfs_rename_key){+.+.}-{4:4}, at: do_renameat2+0x5ea/0x1440 fs/namei.c:5216
 #2: ffff888070bee330 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #2: ffff888070bee330 (&sb->s_type->i_mutex_key#19/1){+.+.}-{4:4}, at: lock_two_directories+0x1a8/0x220 fs/namei.c:3245
 #3: ffff88805b6682a0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #3: ffff88805b6682a0 (&sb->s_type->i_mutex_key#19/5){+.+.}-{4:4}, at: lock_two_directories+0x1d1/0x220 fs/namei.c:3246
 #4: ffff888070bee9a0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:902 [inline]
 #4: ffff888070bee9a0 (&sb->s_type->i_mutex_key#19/2){+.+.}-{4:4}, at: vfs_rename+0x63f/0xf10 fs/namei.c:5084
 #5: ffff88805b6682a0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: inode_lock include/linux/fs.h:867 [inline]
 #5: ffff88805b6682a0 (&sb->s_type->i_mutex_key#19){++++}-{4:4}, at: vfs_rename+0x6b9/0xf10 fs/namei.c:5086
3 locks held by syz-executor/7048:

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

NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 31 Comm: khungtaskd Not tainted 6.15.0-rc3-syzkaller-00032-ga79be02bba5c-dirty #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 nmi_cpu_backtrace+0x4ab/0x4e0 lib/nmi_backtrace.c:113
 nmi_trigger_cpumask_backtrace+0x198/0x320 lib/nmi_backtrace.c:62
 trigger_all_cpu_backtrace include/linux/nmi.h:158 [inline]
 check_hung_uninterruptible_tasks kernel/hung_task.c:274 [inline]
 watchdog+0x1058/0x10a0 kernel/hung_task.c:437
 kthread+0x7b7/0x940 kernel/kthread.c:464
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:153
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 UID: 0 PID: 47 Comm: kworker/u8:3 Not tainted 6.15.0-rc3-syzkaller-00032-ga79be02bba5c-dirty #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Workqueue: bat_events batadv_nc_worker
RIP: 0010:unwind_next_frame+0x188f/0x23b0 arch/x86/kernel/unwind_orc.c:648
Code: 49 83 c7 03 48 89 d8 48 c1 e8 03 0f b6 04 28 84 c0 0f 85 50 0a 00 00 4c 89 f8 48 c1 e8 03 0f b6 04 28 84 c0 0f 85 5c 0a 00 00 <48> 0f bf 03 48 8b 74 24 08 48 01 c6 49 8d 54 24 40 4c 89 e7 e8 38
RSP: 0018:ffffc900000072c8 EFLAGS: 00000246
RAX: 0000000000000000 RBX: ffffffff918407d8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffc90000007400
RBP: dffffc0000000000 R08: ffffc900000073ff R09: 0000000000000000
R10: ffffc900000073f0 R11: fffff52000000e80 R12: ffffc900000073a0
R13: ffffc90000008000 R14: ffffffff918407da R15: ffffffff918407d9
FS:  0000000000000000(0000) GS:ffff888124fcf000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8db9ee7d60 CR3: 000000000eb38000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <IRQ>
 arch_stack_walk+0x11e/0x150 arch/x86/kernel/stacktrace.c:25
 stack_trace_save+0x11a/0x1d0 kernel/stacktrace.c:122
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 unpoison_slab_object mm/kasan/common.c:319 [inline]
 __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345
 kasan_slab_alloc include/linux/kasan.h:250 [inline]
 slab_post_alloc_hook mm/slub.c:4161 [inline]
 slab_alloc_node mm/slub.c:4210 [inline]
 kmem_cache_alloc_node_noprof+0x1f2/0x3b0 mm/slub.c:4262
 kmalloc_reserve+0xa8/0x2a0 net/core/skbuff.c:577
 __alloc_skb+0x1f2/0x480 net/core/skbuff.c:668
 __netdev_alloc_skb+0x105/0xa10 net/core/skbuff.c:732
 netdev_alloc_skb include/linux/skbuff.h:3413 [inline]
 dev_alloc_skb include/linux/skbuff.h:3426 [inline]
 __ieee80211_beacon_get+0x9a7/0x15e0 net/mac80211/tx.c:5475
 ieee80211_beacon_get_tim+0xb7/0x330 net/mac80211/tx.c:5597
 ieee80211_beacon_get include/net/mac80211.h:5648 [inline]
 mac80211_hwsim_beacon_tx+0x3a2/0x860 drivers/net/wireless/virtual/mac80211_hwsim.c:2313
 __iterate_interfaces+0x297/0x570 net/mac80211/util.c:761
 ieee80211_iterate_active_interfaces_atomic+0xd8/0x170 net/mac80211/util.c:797
 mac80211_hwsim_beacon+0xd4/0x1f0 drivers/net/wireless/virtual/mac80211_hwsim.c:2347
 __run_hrtimer kernel/time/hrtimer.c:1761 [inline]
 __hrtimer_run_queues+0x5a6/0xd40 kernel/time/hrtimer.c:1825
 hrtimer_run_softirq+0x19a/0x2c0 kernel/time/hrtimer.c:1842
 handle_softirqs+0x2d6/0x9b0 kernel/softirq.c:579
 __do_softirq kernel/softirq.c:613 [inline]
 invoke_softirq kernel/softirq.c:453 [inline]
 __irq_exit_rcu+0xfb/0x220 kernel/softirq.c:680
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
 sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049
 </IRQ>
 <TASK>
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
RIP: 0010:check_preemption_disabled+0x1e/0x120 lib/smp_processor_id.c:14
Code: 90 90 90 90 90 90 90 90 90 90 90 90 41 57 41 56 41 55 41 54 53 48 83 ec 10 4c 8d 25 3c 31 3d 07 65 49 8b 04 24 48 89 44 24 08 <65> 8b 1d 3f 31 3d 07 65 8b 05 34 31 3d 07 a9 ff ff ff 7f 74 24 65
RSP: 0018:ffffc90000b87980 EFLAGS: 00000282
RAX: a0fb20d63b9f4f00 RBX: ffffffff93651020 RCX: ffff888020e8da00
RDX: 0000000000000000 RSI: ffffffff8ca0e2a0 RDI: ffffffff8ca0e260
RBP: ffffffff8bf24ea5 R08: ffffffff8bf25051 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff93651020
R13: 1ffff1100b4e0b13 R14: ffff88805a7808e0 R15: ffffffff8ed3df20
 rcu_is_watching_curr_cpu include/linux/context_tracking.h:128 [inline]
 rcu_is_watching+0x15/0xb0 kernel/rcu/tree.c:736
 trace_lock_release include/trace/events/lock.h:69 [inline]
 lock_release+0x4e/0x3e0 kernel/locking/lockdep.c:5877
 rcu_lock_release include/linux/rcupdate.h:341 [inline]
 rcu_read_unlock include/linux/rcupdate.h:871 [inline]
 batadv_nc_process_nc_paths+0x2f0/0x3a0 net/batman-adv/network-coding.c:699
 batadv_nc_worker+0x42a/0x610 net/batman-adv/network-coding.c:728
 process_one_work kernel/workqueue.c:3238 [inline]
 process_scheduled_works+0xac3/0x18e0 kernel/workqueue.c:3319
 worker_thread+0x870/0xd50 kernel/workqueue.c:3400
 kthread+0x7b7/0x940 kernel/kthread.c:464
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:153
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>


Tested on:

commit:         a79be02b Fix mis-uses of 'cc-option' for warning disab..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=114b3fcf980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=3bbffc3b5b4301e1
dashboard link: https://syzkaller.appspot.com/bug?extid=321477fad98ea6dd35b7
compiler:       Debian clang version 15.0.6, Debian LLD 15.0.6
patch:          https://syzkaller.appspot.com/x/patch.diff?x=15447d9b980000


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [syzbot] [fs?] INFO: task hung in vfs_rename (2)
  2025-04-24 12:01 ` syzbot
@ 2025-04-24 19:51   ` Al Viro
  0 siblings, 0 replies; 13+ messages in thread
From: Al Viro @ 2025-04-24 19:51 UTC (permalink / raw)
  To: syzbot; +Cc: hdanton, linux-kernel, syzkaller-bugs

On Thu, Apr 24, 2025 at 05:01:03AM -0700, syzbot wrote:
> Hello,
> 
> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> INFO: task hung in vfs_rename

Would it be too much to ask for the "proposed patch" to be posted on the same lists?
Not everyone is willing to start a browser and go digging for links just to get
some context...

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [syzbot] [fs?] INFO: task hung in vfs_rename (2)
  2025-04-22 21:28 [syzbot] [fs?] INFO: task hung in vfs_rename (2) syzbot
  2025-04-23 11:35 ` Jan Kara
@ 2025-05-13 12:00 ` Edward Adam Davis
  2025-05-13 16:15   ` syzbot
  2025-05-13 22:39 ` [PATCH] fs: Additional checks on new and old dir Edward Adam Davis
  2025-07-22 17:51 ` [syzbot] [fs?] INFO: task hung in vfs_rename (2) Kent Overstreet
  3 siblings, 1 reply; 13+ messages in thread
From: Edward Adam Davis @ 2025-05-13 12:00 UTC (permalink / raw)
  To: syzbot+321477fad98ea6dd35b7; +Cc: linux-kernel, syzkaller-bugs

#syz test

diff --git a/fs/namei.c b/fs/namei.c
index 84a0e0b0111c..ff843007ca94 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -5013,7 +5013,7 @@ int vfs_rename(struct renamedata *rd)
 	struct name_snapshot old_name;
 	bool lock_old_subdir, lock_new_subdir;
 
-	if (source == target)
+	if (source == target || old_dir == target)
 		return 0;
 
 	error = may_delete(rd->old_mnt_idmap, old_dir, old_dentry, is_dir);


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [syzbot] [fs?] INFO: task hung in vfs_rename (2)
  2025-05-13 12:00 ` Edward Adam Davis
@ 2025-05-13 16:15   ` syzbot
  0 siblings, 0 replies; 13+ messages in thread
From: syzbot @ 2025-05-13 16:15 UTC (permalink / raw)
  To: eadavis, linux-kernel, syzkaller-bugs

Hello,

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

Reported-by: syzbot+321477fad98ea6dd35b7@syzkaller.appspotmail.com
Tested-by: syzbot+321477fad98ea6dd35b7@syzkaller.appspotmail.com

Tested on:

commit:         e9565e23 Merge tag 'sched_ext-for-6.15-rc6-fixes' of g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1668ecd4580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=6d3b7b9473eaace7
dashboard link: https://syzkaller.appspot.com/bug?extid=321477fad98ea6dd35b7
compiler:       Debian clang version 20.1.2 (++20250402124445+58df0ef89dd6-1~exp1~20250402004600.97), Debian LLD 20.1.2
patch:          https://syzkaller.appspot.com/x/patch.diff?x=17544af4580000

Note: testing is done by a robot and is best-effort only.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH] fs: Additional checks on new and old dir
  2025-04-22 21:28 [syzbot] [fs?] INFO: task hung in vfs_rename (2) syzbot
  2025-04-23 11:35 ` Jan Kara
  2025-05-13 12:00 ` Edward Adam Davis
@ 2025-05-13 22:39 ` Edward Adam Davis
  2025-05-16 19:31   ` Al Viro
  2025-07-22 17:51 ` [syzbot] [fs?] INFO: task hung in vfs_rename (2) Kent Overstreet
  3 siblings, 1 reply; 13+ messages in thread
From: Edward Adam Davis @ 2025-05-13 22:39 UTC (permalink / raw)
  To: syzbot+321477fad98ea6dd35b7
  Cc: brauner, jack, linux-fsdevel, linux-kernel, syzkaller-bugs, viro

In the reproducer, when calling renameat2(), olddirfd and newdirfd passed
are the same value r0, see [1]. This situation should be avoided.

[1]
renameat2(r0, &(0x7f0000000240)='./bus/file0\x00', r0, &(0x7f00000001c0)='./file0\x00', 0x0)

Reported-by: syzbot+321477fad98ea6dd35b7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=321477fad98ea6dd35b7
Tested-by: syzbot+321477fad98ea6dd35b7@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 fs/namei.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/namei.c b/fs/namei.c
index 84a0e0b0111c..ff843007ca94 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -5013,7 +5013,7 @@ int vfs_rename(struct renamedata *rd)
 	struct name_snapshot old_name;
 	bool lock_old_subdir, lock_new_subdir;
 
-	if (source == target)
+	if (source == target || old_dir == target)
 		return 0;
 
 	error = may_delete(rd->old_mnt_idmap, old_dir, old_dentry, is_dir);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH] fs: Additional checks on new and old dir
  2025-05-13 22:39 ` [PATCH] fs: Additional checks on new and old dir Edward Adam Davis
@ 2025-05-16 19:31   ` Al Viro
  2025-05-16 23:20     ` [pox on syzbot - again][exfat] exfat_mkdir() breakage on corrupted image Al Viro
  0 siblings, 1 reply; 13+ messages in thread
From: Al Viro @ 2025-05-16 19:31 UTC (permalink / raw)
  To: Edward Adam Davis
  Cc: syzbot+321477fad98ea6dd35b7, brauner, jack, linux-fsdevel,
	linux-kernel, syzkaller-bugs

On Wed, May 14, 2025 at 06:39:40AM +0800, Edward Adam Davis wrote:
> In the reproducer, when calling renameat2(), olddirfd and newdirfd passed
> are the same value r0, see [1]. This situation should be avoided.
> 
> [1]
> renameat2(r0, &(0x7f0000000240)='./bus/file0\x00', r0, &(0x7f00000001c0)='./file0\x00', 0x0)
> 
> Reported-by: syzbot+321477fad98ea6dd35b7@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=321477fad98ea6dd35b7
> Tested-by: syzbot+321477fad98ea6dd35b7@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>  fs/namei.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index 84a0e0b0111c..ff843007ca94 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -5013,7 +5013,7 @@ int vfs_rename(struct renamedata *rd)
>  	struct name_snapshot old_name;
>  	bool lock_old_subdir, lock_new_subdir;
>  
> -	if (source == target)
> +	if (source == target || old_dir == target)
>  		return 0;

What the hell?

1) olddirfd and newdirfd have nothing to do with vfs_rename() - they are
bloody well gone by the time we get there.

2) there's nothing wrong with having the same value passed in both -
and it's certainly not a "quietly do nothing".

3) the check added in this patch is... odd.  You are checking essentically
for rename("foo/bar", "foo").  It should fail (-ENOTEMPTY or -EINVAL, depending
upon RENAME_EXCHANGE in flags) without having reached vfs_rename().

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [pox on syzbot - again][exfat] exfat_mkdir() breakage on corrupted image
  2025-05-16 19:31   ` Al Viro
@ 2025-05-16 23:20     ` Al Viro
  2025-05-20 17:17       ` Aleksandr Nogikh
  0 siblings, 1 reply; 13+ messages in thread
From: Al Viro @ 2025-05-16 23:20 UTC (permalink / raw)
  To: Edward Adam Davis
  Cc: syzbot+321477fad98ea6dd35b7, brauner, jack, linux-fsdevel,
	linux-kernel, syzkaller-bugs

On Fri, May 16, 2025 at 08:31:22PM +0100, Al Viro wrote:
> On Wed, May 14, 2025 at 06:39:40AM +0800, Edward Adam Davis wrote:
> > In the reproducer, when calling renameat2(), olddirfd and newdirfd passed
> > are the same value r0, see [1]. This situation should be avoided.
> > 
> > [1]
> > renameat2(r0, &(0x7f0000000240)='./bus/file0\x00', r0, &(0x7f00000001c0)='./file0\x00', 0x0)
> > 
> > Reported-by: syzbot+321477fad98ea6dd35b7@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=321477fad98ea6dd35b7
> > Tested-by: syzbot+321477fad98ea6dd35b7@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > ---
> >  fs/namei.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 84a0e0b0111c..ff843007ca94 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -5013,7 +5013,7 @@ int vfs_rename(struct renamedata *rd)
> >  	struct name_snapshot old_name;
> >  	bool lock_old_subdir, lock_new_subdir;
> >  
> > -	if (source == target)
> > +	if (source == target || old_dir == target)
> >  		return 0;
> 
> What the hell?
> 
> 1) olddirfd and newdirfd have nothing to do with vfs_rename() - they are
> bloody well gone by the time we get there.
> 
> 2) there's nothing wrong with having the same value passed in both -
> and it's certainly not a "quietly do nothing".
> 
> 3) the check added in this patch is... odd.  You are checking essentically
> for rename("foo/bar", "foo").  It should fail (-ENOTEMPTY or -EINVAL, depending
> upon RENAME_EXCHANGE in flags) without having reached vfs_rename().

4) it's definitely an exfat bug, since we are getting
	old_dentry->d_parent != target
	old_dentry->d_parent->d_inode == target->d_inode
	S_ISDIR(target->d_inode->i_mode)
All objects involved are on the same super_block, which has "exfat" for
->s_type->name, so it's exfat ending up with multiple dentries for
the same directory inode, and once that kind of thing has happened,
the system is FUBAR.

As for the root cause, almost certainly their ->mkdir() is deciding
that it has just created a new inode - and ending up with existing one,
already in icache and already with a dentry attached to it.

<adds BUG_ON(!hlist_empty(&inode->i_dentry)) into exfat_mkdir()>

   [   84.780875] exFAT-fs (loop0): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
   [   84.781411] exFAT-fs (loop0): Medium has reported failures. Some data may be lost.
   [   84.782209] exFAT-fs (loop0): failed to load upcase table (idx : 0x00010000, chksum : 0xe62de5da, utbl_chksum : 0xe619d30d)
   [   84.783272] ------------[ cut here ]------------
   [   84.783546] kernel BUG at fs/exfat/namei.c:881!

... and there we go.  exfat_mkdir() getting an existing in-core inode
and attaching an alias to it, with expected fun results.

For crying out loud, how many times do syzbot folks need to be told that
getting report to attention of relevant filesystem folks is important?

Subject: [syzbot] [fs?] INFO: task hung in vfs_rename (2)

mentionings of anything exfat-related: 0.

Cc: brauner@kernel.org, jack@suse.cz, linux-fsdevel@vger.kernel.org,
	 linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
		 viro@zeniv.linux.org.uk

mentionings of anything exfat-related: 0.

In message body:
  fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=12655204580000)

Why, that does sound like some filesystem bug might be involved
and presumably the damn thing knows which type had it been.
<start browser, cut'n'paste the sodding link>
... and the very first line is
fsck.exfat -n exited with status code 4

Result: 3 weeks later it *STILL* hasn't reached the relevant fs
maintainers.  Could that be a sufficient evidence to convince the
fine fellows working on syzbot that "you just need to click a few
links" DOES NOT WORK?

We'd been there several times already.  For relatively polite example,
see https://lore.kernel.org/all/Y5ZDjuSNuSLJd8Mn@ZenIV/ - I can't be arsed
to explain that again and again, and you don't seem to mind following
links in email, so...

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [pox on syzbot - again][exfat] exfat_mkdir() breakage on corrupted image
  2025-05-16 23:20     ` [pox on syzbot - again][exfat] exfat_mkdir() breakage on corrupted image Al Viro
@ 2025-05-20 17:17       ` Aleksandr Nogikh
  0 siblings, 0 replies; 13+ messages in thread
From: Aleksandr Nogikh @ 2025-05-20 17:17 UTC (permalink / raw)
  To: Al Viro
  Cc: Edward Adam Davis, syzbot+321477fad98ea6dd35b7, brauner, jack,
	linux-fsdevel, linux-kernel, syzkaller-bugs, syzkaller

Hi Al,

I've only just seen this email as it landed in my Spam folder for some reason.

On Sat, May 17, 2025 at 1:20 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Fri, May 16, 2025 at 08:31:22PM +0100, Al Viro wrote:
> > On Wed, May 14, 2025 at 06:39:40AM +0800, Edward Adam Davis wrote:
> > > In the reproducer, when calling renameat2(), olddirfd and newdirfd passed
> > > are the same value r0, see [1]. This situation should be avoided.
> > >
> > > [1]
> > > renameat2(r0, &(0x7f0000000240)='./bus/file0\x00', r0, &(0x7f00000001c0)='./file0\x00', 0x0)
> > >
> > > Reported-by: syzbot+321477fad98ea6dd35b7@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=321477fad98ea6dd35b7
> > > Tested-by: syzbot+321477fad98ea6dd35b7@syzkaller.appspotmail.com
> > > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > > ---
> > >  fs/namei.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/fs/namei.c b/fs/namei.c
> > > index 84a0e0b0111c..ff843007ca94 100644
> > > --- a/fs/namei.c
> > > +++ b/fs/namei.c
> > > @@ -5013,7 +5013,7 @@ int vfs_rename(struct renamedata *rd)
> > >     struct name_snapshot old_name;
> > >     bool lock_old_subdir, lock_new_subdir;
> > >
> > > -   if (source == target)
> > > +   if (source == target || old_dir == target)
> > >             return 0;
> >
> > What the hell?
> >
> > 1) olddirfd and newdirfd have nothing to do with vfs_rename() - they are
> > bloody well gone by the time we get there.
> >
> > 2) there's nothing wrong with having the same value passed in both -
> > and it's certainly not a "quietly do nothing".
> >
> > 3) the check added in this patch is... odd.  You are checking essentically
> > for rename("foo/bar", "foo").  It should fail (-ENOTEMPTY or -EINVAL, depending
> > upon RENAME_EXCHANGE in flags) without having reached vfs_rename().
>
> 4) it's definitely an exfat bug, since we are getting
>         old_dentry->d_parent != target
>         old_dentry->d_parent->d_inode == target->d_inode
>         S_ISDIR(target->d_inode->i_mode)
> All objects involved are on the same super_block, which has "exfat" for
> ->s_type->name, so it's exfat ending up with multiple dentries for
> the same directory inode, and once that kind of thing has happened,
> the system is FUBAR.
>
> As for the root cause, almost certainly their ->mkdir() is deciding
> that it has just created a new inode - and ending up with existing one,
> already in icache and already with a dentry attached to it.
>
> <adds BUG_ON(!hlist_empty(&inode->i_dentry)) into exfat_mkdir()>
>
>    [   84.780875] exFAT-fs (loop0): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
>    [   84.781411] exFAT-fs (loop0): Medium has reported failures. Some data may be lost.
>    [   84.782209] exFAT-fs (loop0): failed to load upcase table (idx : 0x00010000, chksum : 0xe62de5da, utbl_chksum : 0xe619d30d)
>    [   84.783272] ------------[ cut here ]------------
>    [   84.783546] kernel BUG at fs/exfat/namei.c:881!
>
> ... and there we go.  exfat_mkdir() getting an existing in-core inode
> and attaching an alias to it, with expected fun results.
>
> For crying out loud, how many times do syzbot folks need to be told that
> getting report to attention of relevant filesystem folks is important?
>
> Subject: [syzbot] [fs?] INFO: task hung in vfs_rename (2)
>
> mentionings of anything exfat-related: 0.
>
> Cc: brauner@kernel.org, jack@suse.cz, linux-fsdevel@vger.kernel.org,
>          linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
>                  viro@zeniv.linux.org.uk
>
> mentionings of anything exfat-related: 0.
>
> In message body:
>   fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=12655204580000)
>
> Why, that does sound like some filesystem bug might be involved
> and presumably the damn thing knows which type had it been.
> <start browser, cut'n'paste the sodding link>
> ... and the very first line is
> fsck.exfat -n exited with status code 4
>
> Result: 3 weeks later it *STILL* hasn't reached the relevant fs
> maintainers.  Could that be a sufficient evidence to convince the
> fine fellows working on syzbot that "you just need to click a few
> links" DOES NOT WORK?
>
> We'd been there several times already.  For relatively polite example,
> see https://lore.kernel.org/all/Y5ZDjuSNuSLJd8Mn@ZenIV/ - I can't be arsed
> to explain that again and again, and you don't seem to mind following
> links in email, so...
>

I've checked the code, and there was indeed a bug in our
classification rules, specifically concerning the recognition of the
`syz_mount_image$exfat` call as an indicator for the "exfat"
subsystem. The fix will reach syzbot soon.

Sorry for the inconvenience it has caused.

-- 
Aleksandr

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [syzbot] [fs?] INFO: task hung in vfs_rename (2)
  2025-04-22 21:28 [syzbot] [fs?] INFO: task hung in vfs_rename (2) syzbot
                   ` (2 preceding siblings ...)
  2025-05-13 22:39 ` [PATCH] fs: Additional checks on new and old dir Edward Adam Davis
@ 2025-07-22 17:51 ` Kent Overstreet
  2025-07-23  8:38   ` Jan Kara
  3 siblings, 1 reply; 13+ messages in thread
From: Kent Overstreet @ 2025-07-22 17:51 UTC (permalink / raw)
  To: syzbot; +Cc: brauner, jack, linux-fsdevel, linux-kernel, syzkaller-bugs, viro

Here's another one that someone incorrectly assigned to bcachefs (and I
can't find who's doing it, they're not ccing the list).

But I've got through the logs and there's nothing connecting it to
bcachefs.

#syz set subsystems: fs

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [syzbot] [fs?] INFO: task hung in vfs_rename (2)
  2025-07-22 17:51 ` [syzbot] [fs?] INFO: task hung in vfs_rename (2) Kent Overstreet
@ 2025-07-23  8:38   ` Jan Kara
  0 siblings, 0 replies; 13+ messages in thread
From: Jan Kara @ 2025-07-23  8:38 UTC (permalink / raw)
  To: Kent Overstreet
  Cc: syzbot, brauner, jack, linux-fsdevel, linux-kernel,
	syzkaller-bugs, viro

On Tue 22-07-25 13:51:17, Kent Overstreet wrote:
> Here's another one that someone incorrectly assigned to bcachefs (and I
> can't find who's doing it, they're not ccing the list).
>
> But I've got through the logs and there's nothing connecting it to
> bcachefs.

Well, as far as I know syzbot guys have some automated bot that decides
where to assign bugs based on some heuristics. Apparently there is some
room for improvement :)

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2025-07-23  8:39 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-22 21:28 [syzbot] [fs?] INFO: task hung in vfs_rename (2) syzbot
2025-04-23 11:35 ` Jan Kara
2025-05-13 12:00 ` Edward Adam Davis
2025-05-13 16:15   ` syzbot
2025-05-13 22:39 ` [PATCH] fs: Additional checks on new and old dir Edward Adam Davis
2025-05-16 19:31   ` Al Viro
2025-05-16 23:20     ` [pox on syzbot - again][exfat] exfat_mkdir() breakage on corrupted image Al Viro
2025-05-20 17:17       ` Aleksandr Nogikh
2025-07-22 17:51 ` [syzbot] [fs?] INFO: task hung in vfs_rename (2) Kent Overstreet
2025-07-23  8:38   ` Jan Kara
     [not found] <20250423110503.4262-1-hdanton@sina.com>
2025-04-23 18:39 ` syzbot
     [not found] <20250424110546.4284-1-hdanton@sina.com>
2025-04-24 12:01 ` syzbot
2025-04-24 19:51   ` Al Viro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).