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

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

[Ginger]

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.

Thank you for your time and consideration.

Best regards,
Ginger

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

[Michal Pecio]

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