Re: [bug report] Potential deadlock bug in 'drivers/usb/musb/musb_core.c', between 'musb_g_giveback()' and 'musb_stage0_irq()'

[Michal Pecio <michal.pecio@gmail.com>]

On Fri, 24 Apr 2026 12:50:43 +0800, Ginger wrote:
> Dear Linux kernel maintainers,
> 
> My research-based static analyzer found a potential deadlock bug
> within the 'drivers/usb/musb' subsystem, more specifically, in
> 'drivers/usb/musb/musb_core.c'.
> This deadlock potentially occurs with the involvement of hard irq.
> 
> Kernel version: long-term kernel v6.18.9
> 
> Potential concurrent triggering executions:
> T0:
> musb_stage0_irq [t1]
>      --> musb_handle_intr_resume
>          --> musb_g_resume
>              --> spin_lock(&musb->lock); [t2]  
> 
> T1:
> musb_g_giveback
>     --> spin_lock(&musb->lock); [t0]  
> 
> If T0 (i.e., the hard irq) occurs after T1 acquires the lock and both
> happen within the same CPU, then T0 will not proceed because it cannot
> hold the spin lock that has already been possessed by T1, yet T1
> cannot proceed because the hard irq runs disables preempts.
> Simply speaking, t0 -> t1 -> t2 can lead to a deadlock.

Hi,

You may want to consider earlier operations on the same lock and their
implications. This function releases musb->lock before acquiring it.

If called with the lock unlocked, that's a different kind of bug.
If called with IRQs enabled, the caller created this problem.
If called with IRQs disabled, it won't enable IRQs and won't deadlock.

Regards,
Michal