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@xxxxxxxxxxx/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@xxxxxxxxxxxxx/ 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@xxxxxxxxxxx/t/#u. I have applied your patch: https://lore.kernel.org/all/20250811082745.ycJqBXMs@xxxxxxxxxxxxx/ -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
