Message-ID: <d534be54-3631-45e3-8b85-267b6736c4ca@linux.dev>
Date: Mon, 4 Aug 2025 21:41:07 -0700
From: Yonghong Song <yonghong.song@...ux.dev>
To: syzbot <syzbot+c3740bc819eb55460ec3@...kaller.appspotmail.com>,
 andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org,
 daniel@...earbox.net, eddyz87@...il.com, haoluo@...gle.com,
 john.fastabend@...il.com, jolsa@...nel.org, kpsingh@...nel.org,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 martin.lau@...ux.dev, mathieu.desnoyers@...icios.com,
 mattbobrowski@...gle.com, mhiramat@...nel.org, rostedt@...dmis.org,
 sdf@...ichev.me, song@...nel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [trace?] [bpf?] possible deadlock in down_trylock (3)



On 8/4/25 9:50 AM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    84b92a499e7e Add linux-next specific files for 20250731
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=11065aa2580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=b335f01a07f73eac
> dashboard link: https://syzkaller.appspot.com/bug?extid=c3740bc819eb55460ec3
> compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=14167834580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16f27cf0580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/97d9ce461c85/disk-84b92a49.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/0ca812ed76e7/vmlinux-84b92a49.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/0959d28a047f/bzImage-84b92a49.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+c3740bc819eb55460ec3@...kaller.appspotmail.com
>
> FAULT_INJECTION: forcing a failure.
> name fail_usercopy, interval 1, probability 0, space 0, times 0
> ============================================
> WARNING: possible recursive locking detected
> 6.16.0-next-20250731-syzkaller #0 Not tainted
> --------------------------------------------
> syz.3.22/6137 is trying to acquire lock:
> ffffffff8e12e278 ((console_sem).lock){-...}-{2:2}, at: down_trylock+0x20/0xb0 kernel/locking/semaphore.c:176
>
> but task is already holding lock:
> ffffffff8e12e278 ((console_sem).lock){-...}-{2:2}, at: down+0x39/0xd0 kernel/locking/semaphore.c:96

There is a similar discussion in the following old thread:
    https://lore.kernel.org/bpf/345098dc-8cb4-4808-98cf-fa9ab3af4fc4@I-love.SAKURA.ne.jp/

In that case, the recursive lock is rq lock. Looks like there is no good solution for
that thread.

Not sure how this semaphore deadlock could be resolved.

>
> other info that might help us debug this:
>   Possible unsafe locking scenario:
>
>         CPU0
>         ----
>    lock((console_sem).lock);
>    lock((console_sem).lock);
>
>   *** DEADLOCK ***
>
>   May be due to missing lock nesting notation
>
> 2 locks held by syz.3.22/6137:
>   #0: ffffffff8e12e278 ((console_sem).lock){-...}-{2:2}, at: down+0x39/0xd0 kernel/locking/semaphore.c:96
>   #1: ffffffff8e139f20 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
>   #1: ffffffff8e139f20 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
>   #1: ffffffff8e139f20 (rcu_read_lock){....}-{1:3}, at: __bpf_trace_run kernel/trace/bpf_trace.c:2256 [inline]
>   #1: ffffffff8e139f20 (rcu_read_lock){....}-{1:3}, at: bpf_trace_run2+0x186/0x4b0 kernel/trace/bpf_trace.c:2298
>
> stack backtrace:
> CPU: 0 UID: 0 PID: 6137 Comm: syz.3.22 Not tainted 6.16.0-next-20250731-syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
> Call Trace:
>   <TASK>
>   dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
>   print_deadlock_bug+0x28b/0x2a0 kernel/locking/lockdep.c:3041
>   check_deadlock kernel/locking/lockdep.c:3093 [inline]
>   validate_chain+0x1a3f/0x2140 kernel/locking/lockdep.c:3895
>   __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5237
>   lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868
>   __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>   _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162
>   down_trylock+0x20/0xb0 kernel/locking/semaphore.c:176
>   __down_trylock_console_sem+0xd0/0x1e0 kernel/printk/printk.c:326
>   console_trylock kernel/printk/printk.c:2868 [inline]
>   console_trylock_spinning kernel/printk/printk.c:2009 [inline]
>   vprintk_emit+0x320/0x7a0 kernel/printk/printk.c:2449
>   _printk+0xcf/0x120 kernel/printk/printk.c:2475
>   fail_dump lib/fault-inject.c:66 [inline]
>   should_fail_ex+0x3f5/0x560 lib/fault-inject.c:174
>   strncpy_from_user+0x36/0x290 lib/strncpy_from_user.c:118
>   strncpy_from_user_nofault+0x72/0x150 mm/maccess.c:192
>   bpf_trace_copy_string kernel/bpf/helpers.c:755 [inline]
>   bpf_bprintf_prepare+0xbbc/0x13d0 kernel/bpf/helpers.c:976
>   ____bpf_trace_printk kernel/trace/bpf_trace.c:373 [inline]
>   bpf_trace_printk+0xdb/0x190 kernel/trace/bpf_trace.c:363
>   bpf_prog_7c77c7e0f6645ad8+0x3e/0x44
>   bpf_dispatcher_nop_func include/linux/bpf.h:1322 [inline]
>   __bpf_prog_run include/linux/filter.h:718 [inline]
>   bpf_prog_run include/linux/filter.h:725 [inline]
>   __bpf_trace_run kernel/trace/bpf_trace.c:2257 [inline]
>   bpf_trace_run2+0x284/0x4b0 kernel/trace/bpf_trace.c:2298
>   __bpf_trace_contention_begin+0xdc/0x130 include/trace/events/lock.h:95
>   __do_trace_contention_begin include/trace/events/lock.h:95 [inline]
>   trace_contention_begin include/trace/events/lock.h:95 [inline]
>   __down_common+0x5ad/0x6a0 kernel/locking/semaphore.c:292
>   down+0x80/0xd0 kernel/locking/semaphore.c:100
>   console_lock+0x145/0x1b0 kernel/printk/printk.c:2849
>   do_fb_ioctl+0x509/0x750 drivers/video/fbdev/core/fb_chrdev.c:123
>   vfs_ioctl fs/ioctl.c:51 [inline]
>   __do_sys_ioctl fs/ioctl.c:598 [inline]
>   __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:584
>   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>   do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f92c678eb69
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffda68c54f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007f92c69b5fa0 RCX: 00007f92c678eb69
> RDX: 0000200000000080 RSI: 0000000000004606 RDI: 0000000000000005
> RBP: 00007ffda68c5550 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
> R13: 00007f92c69b5fa0 R14: 00007f92c69b5fa0 R15: 0000000000000003
>   </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@...glegroups.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

Powered by blists - more mailing lists