[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CO1PR11MB5089EB42A97F4A712B14BC53D69E9@CO1PR11MB5089.namprd11.prod.outlook.com>
Date: Fri, 5 Aug 2022 20:12:47 +0000
From: "Keller, Jacob E" <jacob.e.keller@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Jiri Pirko <jiri@...nulli.us>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"idosch@...dia.com" <idosch@...dia.com>,
"petrm@...dia.com" <petrm@...dia.com>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"mlxsw@...dia.com" <mlxsw@...dia.com>,
"saeedm@...dia.com" <saeedm@...dia.com>,
"tariqt@...dia.com" <tariqt@...dia.com>,
"leon@...nel.org" <leon@...nel.org>,
"moshe@...dia.com" <moshe@...dia.com>
Subject: RE: [patch net-next 2/4] net: devlink: convert reload command to take
implicit devlink->lock
> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Friday, August 05, 2022 12:59 PM
> To: Keller, Jacob E <jacob.e.keller@...el.com>
> Cc: Jiri Pirko <jiri@...nulli.us>; netdev@...r.kernel.org; davem@...emloft.net;
> idosch@...dia.com; petrm@...dia.com; pabeni@...hat.com;
> edumazet@...gle.com; mlxsw@...dia.com; saeedm@...dia.com;
> tariqt@...dia.com; leon@...nel.org; moshe@...dia.com
> Subject: Re: [patch net-next 2/4] net: devlink: convert reload command to take
> implicit devlink->lock
>
> On Fri, 5 Aug 2022 16:21:16 +0000 Keller, Jacob E wrote:
> > > Convert reload command to behave the same way as the rest of the
> > > commands and let if be called with devlink->lock held. Remove the
> > > temporary devl_lock taking from drivers. As the DEVLINK_NL_FLAG_NO_LOCK
> > > flag is no longer used, remove it alongside.
> > >
> > > Signed-off-by: Jiri Pirko <jiri@...dia.com>
> >
> > Wasn't reload avoiding the lock done so that drivers could perform other
> devlink operations during reload? Or is that no longer a problem with the recent
> refactors done to move devlink initialization and such earlier so that its now safe?
>
> Drivers have control over the lock now, they can take the lock
> themselves (devl_lock()) and call the "I'm already holding the lock"
> functions. So the expectation is that shared paths used by probe and
> reload will always run under the lock.
Ah perfect. So essentially, they already take the lock and are calling the "i'm locked" version of the functions, but this now moves the take the lock part into core.
Ok great! That sounds better than assuming drivers will take the lock themselves.
Thanks,
Jake
Powered by blists - more mailing lists