Re: [PATCH net-next v2] net: phy: Fix suspicious rcu_dereference usage
From: Russell King (Oracle)
Date: Sun Jan 19 2025 - 09:28:21 EST
On Sun, Jan 19, 2025 at 01:45:18PM +0100, Kory Maincent wrote:
> On Fri, 17 Jan 2025 19:07:20 -0800
> Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> > On Fri, 17 Jan 2025 23:16:59 +0100 Kory Maincent wrote:
> > > > If not protected by RTNL, what prevents two threads from calling this
> > > > function at the same time,
> > > > thus attempting to kfree_rcu() the same pointer twice ?
> > >
> > > I don't think this function can be called simultaneously from two threads,
> > > if this were the case we would have already seen several issues with the
> > > phydev pointer. But maybe I am wrong.
> > >
> > > The rcu_lock here is to prevent concurrent dev->hwprov pointer modification
> > > done under rtnl_lock in net/ethtool/tsconfig.c.
> >
> > I could also be wrong, but I don't recall being told that suspend path
> > can't race with anything else. So I think ravb should probably take
> > rtnl_lock or some such when its shutting itself down.. ?
>
> Should we add an ASSERT_RTNL call in the phy_detach function? (Maybe
> also in phy_attach to be consistent)
> Even thought, I think it may raise lots of warning from other NIT drivers.
How many drivers use phy_detach() ?
The answer is... phylink, bcm genet and xgbe.
Of the phylink ones:
1. phylink_connect_phy() - for use by drivers. This had better be
called _before_ the netdev is registered (without rtnl) or
from .ndo_open that holds the RTNL.
2. phylink_fwnode_phy_connect() - same as above.
3. phylink_sfp_config_phy(), called from the SFP code, and its state
machines. It will be holding RTNL, because it is only safe to
attach and detach PHYs from a registered netdev while holding RTNL.
I haven't looked any further.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!