linux-kernel - Re: [PATCH net v1 1/1] net: usb: asix: forbid runtime PM to avoid PM/MDIO + RTNL deadlock

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <aND2jWYm8k5sD4nV@pengutronix.de>
Date: Mon, 22 Sep 2025 09:11:09 +0200
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Lukas Wunner <lukas@...ner.de>
Cc: Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Hubert Wi??niewski <hubert.wisniewski.25632@...il.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>, stable@...r.kernel.org,
	kernel@...gutronix.de, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Russell King <linux@...linux.org.uk>,
	Xu Yang <xu.yang_2@....com>, linux-usb@...r.kernel.org
Subject: Re: [PATCH net v1 1/1] net: usb: asix: forbid runtime PM to avoid
 PM/MDIO + RTNL deadlock

Hi Lukas,

On Wed, Sep 17, 2025 at 08:58:17PM +0200, Lukas Wunner wrote:
> On Wed, Sep 17, 2025 at 11:54:57AM +0200, Oleksij Rempel wrote:
> > Forbid USB runtime PM (autosuspend) for AX88772* in bind.
> [...]
> > With autosuspend active, resume paths may require calling phylink/phylib
> > (caller must hold RTNL) and doing MDIO I/O. Taking RTNL from a USB PM
> > resume can deadlock (RTNL may already be held), and MDIO can attempt a
> > runtime-wake while the USB PM lock is held.
> 
> FWIW, for smsc95xx.c, the MDIO deadlock issue was resolved by commit
> 7b960c967f2a ("usbnet: smsc95xx: Fix deadlock on runtime resume").
> I would assume that something similar would be possible for
> asix_devices.c as well.

thanks for the recommendation.

Right now I’m juggling two goals:
- Stable: provide a simple and robust fix with minimal risk.
- net-next: design a clean and reliable solution that keeps autosuspend
  working.

For -stable, keeping autosuspend disabled per AX88772* seems to be the
most straightforward and low-risk way to avoid the problematic
autoresume path. Autosuspend isn’t on by default in most distros anyway,
so the behavioral impact is minimal.

If we keep autosuspend enabled, the driver has to be careful about
multiple contexts:
- Runtime PM callbacks: asix_{suspend,resume,reset_resume} running under
the USB PM lock.

- System sleep/resume: asix_resume() via dpm_run_callback() workqueues (no
pm_runtime involved).

- ndo_open() path (RTNL held): usbnet_open() -> usb_autopm_get_interface()
  -> synchronous autoresume into asix_resume().

- ethtool / netlink control paths: often under RTNL, may trigger
  autoresume and/or MDIO via phylib.

- phylink/MAC ops: may touch MDIO; caller is expected to hold RTNL.

- status URB / NAPI: atomic/BH context (no sleeping, no RTNL).

If maintainers prefer attempting the smsc95xx-style change right away, I
can draft it; my preference for -stable is still the minimal forbid to
limit churn.

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |