From: Jakub Kicinski <kuba@kernel.org>
To: "Keller, Jacob E" <jacob.e.keller@intel.com>
Cc: Jiri Pirko <jiri@resnulli.us>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"idosch@nvidia.com" <idosch@nvidia.com>,
"petrm@nvidia.com" <petrm@nvidia.com>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"edumazet@google.com" <edumazet@google.com>,
"mlxsw@nvidia.com" <mlxsw@nvidia.com>,
"saeedm@nvidia.com" <saeedm@nvidia.com>,
"tariqt@nvidia.com" <tariqt@nvidia.com>,
"leon@kernel.org" <leon@kernel.org>,
"moshe@nvidia.com" <moshe@nvidia.com>
Subject: Re: [patch net-next 2/4] net: devlink: convert reload command to take implicit devlink->lock
Date: Fri, 5 Aug 2022 12:58:43 -0700 [thread overview]
Message-ID: <20220805125843.540fbc9c@kernel.org> (raw)
In-Reply-To: <CO1PR11MB50899F33FF6F1B95CD3F1B11D69E9@CO1PR11MB5089.namprd11.prod.outlook.com>
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@nvidia.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.
next prev parent reply other threads:[~2022-08-05 19:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-29 7:10 [patch net-next 0/4] net: devlink: allow parallel commands on multiple devlinks Jiri Pirko
2022-07-29 7:10 ` [patch net-next 1/4] net: devlink: introduce "unregistering" mark and use it during devlinks iteration Jiri Pirko
2022-07-29 7:10 ` [patch net-next 2/4] net: devlink: convert reload command to take implicit devlink->lock Jiri Pirko
2022-08-05 16:21 ` Keller, Jacob E
2022-08-05 19:58 ` Jakub Kicinski [this message]
2022-08-05 20:12 ` Keller, Jacob E
2022-07-29 7:10 ` [patch net-next 3/4] net: devlink: remove devlink_mutex Jiri Pirko
2022-07-29 7:10 ` [patch net-next 4/4] net: devlink: enable parallel ops on netlink interface Jiri Pirko
2022-08-20 19:44 ` Jakub Kicinski
2022-08-22 12:26 ` Jiri Pirko
2022-07-30 3:04 ` [patch net-next 0/4] net: devlink: allow parallel commands on multiple devlinks Jakub Kicinski
2022-07-30 9:26 ` Jiri Pirko
2022-07-30 15:53 ` Ido Schimmel
2022-07-31 6:02 ` Ido Schimmel
2022-08-01 11:40 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220805125843.540fbc9c@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=jacob.e.keller@intel.com \
--cc=jiri@resnulli.us \
--cc=leon@kernel.org \
--cc=mlxsw@nvidia.com \
--cc=moshe@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).