Re: [BUG] usb: sleepable spinlock used in USB bh_worker softirq on PREEMPT_RT

[Yunseong Kim <ysk@kzalloc.com>]

Hi Sebastian,

Thank you for your prompt reply and clarification.

On 8/11/25 6:15 오후, Sebastian Andrzej Siewior wrote:
> On 2025-08-11 00:05:49 [+0900], Yunseong Kim wrote:
>> While running a PREEMPT_RT-enabled kernel I observed a sleepable
>> spinlock (rt_spin_lock) being taken from a softirq context within
>> the USB core framework. On PREEMPT_RT, spin_lock() may sleep when
>> contended. This is unsafe in softirq context and can cause hangs or
>> deadlocks.
>>
> …
>> I believe this requires a change in the USB core framework rather than
>> just in individual drivers.
>>
>> Kernel config, full logs, and reproduction steps can be provided on
>> request.
>>
>> This bug was uncovered during my work to fixing KCOV for PREEMPT_RT awareness.
>> Link: https://lore.kernel.org/all/ee26e7b2-80dd-49b1-bca2-61e460f73c2d@kzalloc.com/t/#u
> 
> I'm confused. Is this new or this the same bug that was reported by you
> in the thread you linked?
> The kcov issue should be fixed by
> 	https://lore.kernel.org/all/20250811082745.ycJqBXMs@linutronix.de/

You are absolutely right.

While PREEMPT_RT does shift most softirq handling to the ksoftirqd process
context where sleeping locks are generally allowed, I overlooked the ironclad
rule: DO NOT SLEEP if interrupts are disabled. Even in ksoftirqd, disabling
interrupts creates an atomic context, and acquiring a sleeping lock while
irqs_disabled() is true can be disastrous in real-time environments.

The bug I reported, specifically the call stack observed where rt_spin_lock was
taken from a softirq context within the USB core framework, was a direct
consequence of this misunderstanding. This issue was uncovered during my work on
fixing KCOV for PREEMPT_RT awareness and was consistently reproducible across my
v1 through v3 patches. For reference, my v3 work can be found here:
 https://lore.kernel.org/lkml/ddd14f62-b6c9-4984-84be-6c999ea92e30@kzalloc.com/t/#u.

I have applied your patch:
 https://lore.kernel.org/all/20250811082745.ycJqBXMs@linutronix.de/

-static inline unsigned long kcov_remote_start_usb_softirq(u64 id)
+static inline void kcov_remote_start_usb_softirq(u64 id)
 {
-	unsigned long flags = 0;
-
-	if (in_serving_softirq()) {
-		local_irq_save(flags);
+	if (in_serving_softirq() && !in_hardirq())
 		kcov_remote_start_usb(id);

!in_hardirq(), I can definitely confirm that the specific call stack and the bug
I reported are no longer reproducible. Your fix has indeed addressed the
underlying issue.

>> Best Regards,
>> Yunseong Kim
> 
> Sebastian


Thank you again for your guidance and for resolving this problem!

Best Regards,
Yunseong Kim