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

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

On 2026-05-22 15:21:43 [+0800], Hillf Danton wrote:
> > > On RT spinlock is replaced with mutex, and softirq can be raised in the
> > > irq that could come any moment after spin_lock_irqsave().
> > 
> > That is true on the other hand. That means having raised another tasklet
> > could lead to the backtrace. But it would have been two different locks,
> > not blocking on each other.
> >
> The last question, by two different locks, do you mean that the
> tasklet_sync_callback.cb_lock is per cpu?

Yes, it is but this does not matter. kbd_led_trigger_activate() does
tasklet_disable(&keyboard_tasklet) so you can't have kbd_bh() running
and led_set_brightness() which would kick the softirq again. Not from
kbd_led_trigger_activate().

Even if another component would raise a softirq in that window, you
could run tasklets, yes, but never kbd_bh(). Not in this window.

So the kbd_led_trigger_activate() -> input_inject_event() needs to be a
different event device than kbd_propagate_led_state() -> event. I don't
see how you could unfold this.

I *think* lockdep observed all this possible interactions and sketched
this possibility but it does not know about tasklet_disable().

I do have an idea how to avoid alloc_skb() invoking softirqs if someone
else raised them while alloc_skb() was preempted. This could avoid this
kind of splat.

Sebastian