[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250123153817.398ee16f@kmaincent-XPS-13-7390>
Date: Thu, 23 Jan 2025 15:38:17 +0100
From: Kory Maincent <kory.maincent@...tlin.com>
To: Claudiu Beznea <claudiu.beznea@...on.dev>
Cc: Paul Barker <paul.barker.ct@...renesas.com>, Niklas Söderlund <niklas.soderlund@...natech.se>, 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>, Mikhail Ulyanov
<mikhail.ulyanov@...entembedded.com>, Sergei Shtylyov
<sergei.shtylyov@...entembedded.com>, Thomas Petazzoni
<thomas.petazzoni@...tlin.com>, Niklas Söderlund
<niklas.soderlund+renesas@...natech.se>, Claudiu Beznea
<claudiu.beznea.uj@...renesas.com>, netdev@...r.kernel.org,
linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 1/2] net: ravb: Fix missing rtnl lock in suspend
path
On Thu, 23 Jan 2025 16:17:58 +0200
Claudiu Beznea <claudiu.beznea@...on.dev> wrote:
> On 23.01.2025 16:08, Kory Maincent wrote:
> > On Thu, 23 Jan 2025 13:33:30 +0200
> > Claudiu Beznea <claudiu.beznea@...on.dev> wrote:
> >
> >> Hi, Kory,
> >>
> >> On 22.01.2025 18:19, Kory Maincent wrote:
> [...]
> >
> >>
> >> I've test it. Looks good.
> >>
> >> Thank you for your patch. However, I think this could be simplified. The
> >> locking scheme looks complicated to me. E.g., this one works too:
> >>
> >> diff --git a/drivers/net/ethernet/renesas/ravb_main.c
> >> b/drivers/net/ethernet/renesas/ravb_main.c
> >> index bc395294a32d..cfe4f0f364f3 100644
> >> --- a/drivers/net/ethernet/renesas/ravb_main.c
> >> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> >> @@ -3217,10 +3217,16 @@ static int ravb_suspend(struct device *dev)
> >>
> >> netif_device_detach(ndev);
> >>
> >> - if (priv->wol_enabled)
> >> - return ravb_wol_setup(ndev);
> >> + if (priv->wol_enabled) {
> >> + rtnl_lock();
> >> + ret = ravb_wol_setup(ndev);
> >> + rtnl_unlock();
> >> + return ret;
> >> + }
> >
> > What happen if wol_enabled flag changes it state between the rtnl_lock and
> > the if condition? We will be in the wrong path.
>
> wol_enabled flag can't change in this suspend phase. The user space tasks
> are fronzen when ravb_suspend() is called.
Oh ok, I don't now the suspend path but if it can't conflict we can got for your
proposition.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Powered by blists - more mailing lists