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

[Hillf Danton]

On Fri, 22 May 2026 09:35:08 +0200 Sebastian Andrzej Siewior wrote:
> 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.
> 
After a look at fd4e876f59b7 ("softirq: Provide a handshake for canceling
tasklets via polling") add a shameless question (obvious the above one is
not last), any chance for cutting tasklet_sync_callback off if wait_on_bit()
for TASKLET_STATE_RUN is used in tasklet_unlock_spin_wait()?