[syzbot] [trace?] [bpf?] possible deadlock in down_trylock (3)

10 views
Skip to first unread message

syzbot

unread,
Aug 4, 2025, 12:50:32 PMAug 4
to and...@kernel.org, a...@kernel.org, b...@vger.kernel.org, dan...@iogearbox.net, edd...@gmail.com, hao...@google.com, john.fa...@gmail.com, jo...@kernel.org, kps...@kernel.org, linux-...@vger.kernel.org, linux-tra...@vger.kernel.org, marti...@linux.dev, mathieu....@efficios.com, mattbo...@google.com, mhir...@kernel.org, ros...@goodmis.org, s...@fomichev.me, so...@kernel.org, syzkall...@googlegroups.com, yongho...@linux.dev
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+c3740b...@syzkaller.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

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

Hillf Danton

unread,
Aug 4, 2025, 11:13:33 PMAug 4
to syzbot, b...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
> Date: Mon, 04 Aug 2025 09:50:30 -0700 [thread overview]
Because down_trylock can be used from interrupt context and the semaphore can
be released by any task or interrupt, testing with bpf enabled wastes minutes.

Yonghong Song

unread,
Aug 5, 2025, 12:41:31 AMAug 5
to syzbot, and...@kernel.org, a...@kernel.org, b...@vger.kernel.org, dan...@iogearbox.net, edd...@gmail.com, hao...@google.com, john.fa...@gmail.com, jo...@kernel.org, kps...@kernel.org, linux-...@vger.kernel.org, linux-tra...@vger.kernel.org, marti...@linux.dev, mathieu....@efficios.com, mattbo...@google.com, mhir...@kernel.org, ros...@goodmis.org, s...@fomichev.me, so...@kernel.org, syzkall...@googlegroups.com
There is a similar discussion in the following old thread:
https://lore.kernel.org/bpf/345098dc-8cb4-4808...@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.
Reply all
Reply to author
Forward
0 new messages