linux-kernel - Re: [PATCH net-next RFC] net: Throw ASSERT_RTNL into phy

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <44e36ef6-6ee4-4cc5-87a9-aa6441eb0e16@lunn.ch>
Date: Sat, 21 Jun 2025 09:48:57 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Kory Maincent <kory.maincent@...tlin.com>
Cc: netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-actions@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-renesas-soc@...r.kernel.org, linux-usb@...r.kernel.org,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	thomas.petazzoni@...tlin.com, 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>,
	Andreas Färber <afaerber@...e.de>,
	Manivannan Sadhasivam <mani@...nel.org>,
	Mark Einon <mark.einon@...il.com>,
	Shyam Sundar S K <Shyam-sundar.S-k@....com>,
	Iyappan Subramanian <iyappan@...amperecomputing.com>,
	Keyur Chudgar <keyur@...amperecomputing.com>,
	Quan Nguyen <quan@...amperecomputing.com>,
	Łukasz Stelmach <l.stelmach@...sung.com>,
	Michael Chan <michael.chan@...adcom.com>,
	Rafał Miłecki <rafal@...ecki.pl>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	Doug Berger <opendmb@...il.com>,
	Florian Fainelli <florian.fainelli@...adcom.com>,
	Pavan Chebbi <pavan.chebbi@...adcom.com>,
	Sunil Goutham <sgoutham@...vell.com>,
	Hans Ulli Kroll <ulli.kroll@...glemail.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Ioana Ciornei <ioana.ciornei@....com>,
	Jijie Shao <shaojijie@...wei.com>,
	Jian Shen <shenjian15@...wei.com>,
	Salil Mehta <salil.mehta@...wei.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Parthiban Veerasooran <parthiban.veerasooran@...rochip.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
	Niklas Söderlund <niklas.soderlund@...natech.se>,
	MD Danish Anwar <danishanwar@...com>,
	Roger Quadros <rogerq@...nel.org>,
	Jiawen Wu <jiawenwu@...stnetic.com>,
	Mengyuan Lou <mengyuanlou@...-swift.com>,
	Imre Kaloz <kaloz@...nwrt.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	Steve Glendinning <steve.glendinning@...well.net>,
	UNGLinuxDriver@...rochip.com, Simon Horman <horms@...nel.org>,
	Vladimir Oltean <olteanv@...il.com>,
	Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH net-next RFC] net: Throw ASSERT_RTNL into phy_detach

On Fri, Jun 20, 2025 at 04:33:27PM +0200, Kory Maincent wrote:
> phy_detach needs the rtnl lock to be held. It should have been added before
> to avoid this massive change among lots of net drivers but there was no
> clear evidence of such needs at that time. This imply a lock change in
> this API. Add phy_detach_rtnl, phy_diconnect_rtnl, phylink_connect_phy_rtnl
> and phylink_fwnode_phy_connect_rtnl helpers to take the lock before calling
> their respective function.

Did you count how many instances don't need to take the lock, because
it is already held? I'm just wondering if the opposite patch would be
smaller, making phy_detach() take RTNL, and add a new function which
does not.

	Andrew