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

[Hillf Danton]

On Fri, 22 May 2026 08:39:38 +0200 Sebastian Andrzej Siewior wrote:
> On 2026-05-22 06:35:14 [+0800], Hillf Danton wrote:
> > input_inject_event() is invoked in the brightness_set callback [1] for
> > example.
> > 
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/input/input-leds.c#n142
> > 
> > > 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
> > 
> > Can you please specify why that is illegal on !RT?
> 
> So if you do
> 	spin_lock_irq();
> 	local_bh_disable();
> 
> then the
> 	local_bh_enable();
> 
> has lockdep_assert_irqs_enabled() which will yell. Then there is also

Ah got it, thanks.

> this local_irq_enable() which will enable interrupts before the unlock
> which bad, again. Also, should softirqs been raised within this section,
> the this enable will invoke the required callback which again, enable
> interrupts.
> 
> > > it is okay but then local_bh_enable() here should not invoke any
> > > softirqs because none were raised within the section (alloc_skb()).
> > 
> > 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?