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

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

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

Sebastian