linux-kernel - Re: [RFC PATCH] usb: gadget: u_ether: prevent deadlock under RT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANp-EDYH8YF7ga5oRPrawhiveSVwW0w7YosHGJWuCKd4TaApDA@mail.gmail.com>
Date: Fri, 7 Mar 2025 14:51:18 -0500
From: Ralph Siemsen <ralph.siemsen@...aro.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-rt-devel@...ts.linux.dev, linux-usb@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Pawel Laszczak <pawell@...ence.com>, 
	Frank Li <Frank.Li@....com>, Ferry Toth <ftoth@...londelft.nl>, 
	Thomas Gleixner <tglx@...utronix.de>, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [RFC PATCH] usb: gadget: u_ether: prevent deadlock under RT

Hi Sebastian,

Thanks for your reply!

On Wed, Feb 26, 2025 at 3:29 AM Sebastian Andrzej Siewior
<bigeasy@...utronix.de> 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