[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8e2a8567d79141f8f5cb180be656efb378dcfee8.camel@sipsolutions.net>
Date: Fri, 14 May 2021 13:22:56 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Nikolai Zhubr <zhubr.2@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net-next] alx: use fine-grained locking instead of RTNL
On Fri, 2021-05-14 at 13:59 +0300, Nikolai Zhubr wrote:
> Hi Johannes,
>
> 12.05.2021 13:19, Johannes Berg:
> > In the alx driver, all locking depended on the RTNL, but
> [...]
> > @@ -232,7 +240,7 @@ static int alx_set_pauseparam(struct net_device *netdev,
> > if (pause->autoneg)
> > fc |= ALX_FC_ANEG;
> >
> > - ASSERT_RTNL();
> > + mutex_lock(&alx->mtx);
> >
> > /* restart auto-neg for auto-mode */
> > if (hw->adv_cfg& ADVERTISED_Autoneg) {
> > @@ -254,6 +262,7 @@ static int alx_set_pauseparam(struct net_device *netdev,
> > alx_cfg_mac_flowcontrol(hw, fc);
> >
> > hw->flowctrl = fc;
> > + mutex_unlock(&alx->mtx);
> >
> > return 0;
> > }
>
> Isn't this fragment missing a mutex_unlock(&alx->mtx) for the "return
> err" codepath in the middle? I'm not sure, its like very suspicious,
> please have a look.
I clearly missed it, somebody already picked up on it:
https://lore.kernel.org/r/20210514082405.91011-1-pulehui@huawei.com
johannes
Powered by blists - more mailing lists