Re: [PATCH net-next v3] net: phy: Fix suspicious rcu_dereference usage

Kory Maincent
2025-01-21T09:38:55Z

On Mon, 20 Jan 2025 11:12:28 -0800
Jakub Kicinski <kuba@kernel.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