Hi Sebastian,
Thanks for your reply!
On Wed, Feb 26, 2025 at 3:29 AM Sebastian Andrzej Siewior
<bigeasy@xxxxxxxxxxxxx> wrote:
> Based on the backtrace the problem is within the cdns3. The driver
> acquires at the beginning of its threaded routine
> spin_lock_irqsave(&priv_dev->lock, flags);
>
> and then before returning the URB it does
> spin_unlock(&priv_dev->lock);
> usb_gadget_giveback_request()
>
> so the lock is dropped but the interrupts are still disabled. This makes
> me wonder why using threaded interrupts at all since interrupts are
> disabled for the whole routine but then others do the same.
I also wondered why threaded interrupts are being used, but I don't
know the reason.
> If you look at dwc3_thread_interrupt() they have local_bh_disable()/
> enable() before acquiring the lock and this is what I would suggest
> doing here, too. The NCM is probably not the only one affected but
> everything doing network that may since it may recourse into softirq.
Thanks for the suggestion. I had also thought of doing this. I also
noticed that the "cdnsp" driver has a similar fix in commit
58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM
gadget"), which was also backported to stable branches. So I will
prepare a v2 patch to do the same for "cdns3" driver.
Regards
Ralph
