Re: [syzbot] [input?] possible deadlock in tasklet_action_common (2)

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-05-21 09:52:32 [+0800], Hillf Danton wrote:
> > Date: Wed, 20 May 2026 10:05:38 -0700	[thread overview]
> > Hello,
> > 
> > syzbot found the following issue on:
> > 
> > HEAD commit:    e98d21c170b0 Add linux-next specific files for 20260508
> > git tree:       linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1354bfce580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=59b98218d9b2edf4
> > dashboard link: https://syzkaller.appspot.com/bug?extid=b5d7ab56d43de3fd5aac
> > compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
> > 
> > Unfortunately, I don't have any reproducer for this issue yet.
> > 
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/66f2a00ee290/disk-e98d21c1.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/6b982257ce9e/vmlinux-e98d21c1.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/a73fbea43e1a/bzImage-e98d21c1.xz
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+b5d7ab56d43de3fd5aac@syzkaller.appspotmail.com
> > 
> > ======================================================
> > WARNING: possible circular locking dependency detected
> > syzkaller #0 Tainted: G             L     
> > ------------------------------------------------------
> > syz.2.4328/32663 is trying to acquire lock:
> > ffff8880b8724168 (tasklet_sync_callback.cb_lock){+...}-{3:3}, at: spin_lock include/linux/spinlock_rt.h:45 [inline]
> > ffff8880b8724168 (tasklet_sync_callback.cb_lock){+...}-{3:3}, at: tasklet_lock_callback kernel/softirq.c:881 [inline]
> > ffff8880b8724168 (tasklet_sync_callback.cb_lock){+...}-{3:3}, at: tasklet_action_common+0xc5/0x610 kernel/softirq.c:931
> > 
> > but task is already holding lock:
> > ffff888058598270 (&dev->event_lock#2){+.+.}-{3:3}, at: spin_lock include/linux/spinlock_rt.h:45 [inline]
> > ffff888058598270 (&dev->event_lock#2){+.+.}-{3:3}, at: class_spinlock_irqsave_constructor include/linux/spinlock.h:619 [inline]
> > ffff888058598270 (&dev->event_lock#2){+.+.}-{3:3}, at: input_inject_event+0xa4/0x320 drivers/input/input.c:419
> > 
> > which lock already depends on the new lock.
> > 
> > 
> > the existing dependency chain (in reverse order) is:
> > 
> > -> #1 (&dev->event_lock#2){+.+.}-{3:3}:
> >        rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56
> >        spin_lock include/linux/spinlock_rt.h:45 [inline]
> >        class_spinlock_irqsave_constructor include/linux/spinlock.h:619 [inline]
> >        input_inject_event+0xa4/0x320 drivers/input/input.c:419
> >        led_trigger_event+0x13b/0x220 drivers/leds/led-triggers.c:420
> >        kbd_propagate_led_state drivers/tty/vt/keyboard.c:1118 [inline]
> >        kbd_bh+0x1b4/0x2c0 drivers/tty/vt/keyboard.c:1297
> >        tasklet_action_common+0x31c/0x610 kernel/softirq.c:942
> >        handle_softirqs+0x1de/0x6d0 kernel/softirq.c:626
> >        __do_softirq kernel/softirq.c:660 [inline]
> >        run_ktimerd+0x69/0x100 kernel/softirq.c:1155
> >        smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
> >        kthread+0x388/0x470 kernel/kthread.c:436
> >        ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
> >        ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

This is obvious and looks fine.

> Deadlock if the timer thread is preempted
> 
> 	timer thread
> 	tasklet_sync_callback.cb_lock
> 
> 	// preempted
> 		&dev->event_lock
> 		do softirq
> 		acquire tasklet_sync_callback.cb_lock
> 
> 	acquire &dev->event_lock

This shouldn't happen.

> > -> #0 (tasklet_sync_callback.cb_lock){+...}-{3:3}:
> >        check_prev_add kernel/locking/lockdep.c:3167 [inline]
> >        check_prevs_add kernel/locking/lockdep.c:3286 [inline]
> >        validate_chain kernel/locking/lockdep.c:3910 [inline]
> >        __lock_acquire+0x15a5/0x2d10 kernel/locking/lockdep.c:5239
> >        lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5870
> >        rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56
> >        spin_lock include/linux/spinlock_rt.h:45 [inline]
> >        tasklet_lock_callback kernel/softirq.c:881 [inline]
> >        tasklet_action_common+0xc5/0x610 kernel/softirq.c:931
> >        handle_softirqs+0x1de/0x6d0 kernel/softirq.c:626
> >        __do_softirq kernel/softirq.c:660 [inline]
> >        __local_bh_enable_ip+0x170/0x2b0 kernel/softirq.c:302
> >        local_bh_enable include/linux/bottom_half.h:33 [inline]
> >        __alloc_skb+0x1aa/0x7d0 net/core/skbuff.c:697
> >        alloc_skb include/linux/skbuff.h:1381 [inline]
> >        hidp_send_message+0xb5/0x230 net/bluetooth/hidp/core.c:111
> >        hidp_send_intr_message net/bluetooth/hidp/core.c:143 [inline]
> >        hidp_input_event+0x2a4/0x380 net/bluetooth/hidp/core.c:175
> >        input_event_dispose+0x80/0x6b0 drivers/input/input.c:322
> >        input_inject_event+0x1d7/0x320 drivers/input/input.c:424

up to kbd_led_trigger_activate(), I can follow. In
kbd_led_trigger_activate() it disables the keyboard tasklet and then
does led_set_brightness(). Not sure how it ends up in
input_inject_event().

Now, input_inject_event() does spin_lock_irqsave() and alloc_skb() does
local_bh_disable()/ local_bh_enable(). On !RT this is not legal. On RT
it is okay but then local_bh_enable() here should not invoke any
softirqs because none were raised within the section (alloc_skb()).
Not sure if this really did occur as such or lockdep comes with the
shortest backtrace based on the lockclass and this is it.

> >        kbd_led_trigger_activate+0xbc/0x100 drivers/tty/vt/keyboard.c:1074
> >        led_trigger_set+0x53b/0x960 drivers/leds/led-triggers.c:220
> >        led_match_default_trigger drivers/leds/led-triggers.c:277 [inline]
> >        led_trigger_set_default+0x266/0x2a0 drivers/leds/led-triggers.c:300
> >        led_classdev_register_ext+0x787/0x9c0 drivers/leds/led-class.c:581
> >        led_classdev_register include/linux/leds.h:274 [inline]
> >        input_leds_connect+0x517/0x790 drivers/input/input-leds.c:145
> >        input_attach_handler drivers/input/input.c:1011 [inline]
> >        input_register_device+0xce0/0x1140 drivers/input/input.c:2395
> >        hidp_session_dev_add net/bluetooth/hidp/core.c:861 [inline]
> >        hidp_session_probe+0x1a5/0x8a0 net/bluetooth/hidp/core.c:1139
> >        l2cap_register_user+0xc2/0x1d0 net/bluetooth/l2cap_core.c:1725
> >        hidp_connection_add+0x158b/0x1a20 net/bluetooth/hidp/core.c:1411
> >        do_hidp_sock_ioctl net/bluetooth/hidp/sock.c:81 [inline]
> >        hidp_sock_ioctl+0x403/0x650 net/bluetooth/hidp/sock.c:128
> >        sock_do_ioctl+0x101/0x320 net/socket.c:1328
> >        sock_ioctl+0x5c9/0x7f0 net/socket.c:1449
> >        vfs_ioctl fs/ioctl.c:51 [inline]
> >        __do_sys_ioctl fs/ioctl.c:597 [inline]
> >        __se_sys_ioctl+0xff/0x170 fs/ioctl.c:583
> >        do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> >        do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94

Sebastian