[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250121103845.6e135477@kmaincent-XPS-13-7390>
Date: Tue, 21 Jan 2025 10:38:45 +0100
From: Kory Maincent <kory.maincent@...tlin.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, Claudiu Beznea
<claudiu.beznea.uj@...renesas.com>, thomas.petazzoni@...tlin.com, Andrew
Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, Russell King
<linux@...linux.org.uk>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
<pabeni@...hat.com>
Subject: Re: [PATCH net-next v3] net: phy: Fix suspicious rcu_dereference
usage
On Mon, 20 Jan 2025 11:12:28 -0800
Jakub Kicinski <kuba@...nel.org> wrote:
> On Mon, 20 Jan 2025 15:19:25 +0100 Kory Maincent wrote:
> > The path reported to not having RTNL lock acquired is the suspend path of
> > the ravb MAC driver. Without this fix we got this warning:
>
> I maintain that ravb is buggy, plenty of drivers take rtnl_lock
> from the .suspend callback. We need _some_ write protection here,
> the patch as is only silences a legitimate warning.
Indeed if the suspend path is buggy we should fix it. Still there is lots of
ethernet drivers calling phy_disconnect without rtnl (IIUC) if probe return an
error or in the remove path. What should we do about it?
About ravb suspend, I don't have the board, Claudiu could you try this instead
of the current fix:
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c index bc395294a32d..c9a0d2d6f371
100644 --- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -3215,15 +3215,22 @@ static int ravb_suspend(struct device *dev)
if (!netif_running(ndev))
goto reset_assert;
+ rtnl_lock();
netif_device_detach(ndev);
- if (priv->wol_enabled)
- return ravb_wol_setup(ndev);
+ if (priv->wol_enabled) {
+ ret = ravb_wol_setup(ndev);
+ rtnl_unlock();
+ return ret;
+ }
ret = ravb_close(ndev);
- if (ret)
+ if (ret) {
+ rtnl_unlock();
return ret;
+ }
+ rtnl_unlock();
ret = pm_runtime_force_suspend(&priv->pdev->dev);
if (ret)
return ret;
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Powered by blists - more mailing lists