From: Leon Romanovsky <leon@kernel.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: davem@davemloft.net, netdev@vger.kernel.org, jiri@resnulli.us,
saeedm@nvidia.com, idosch@idosch.org, michael.chan@broadcom.com,
simon.horman@corigine.com
Subject: Re: [PATCH net-next 5/5] devlink: hold the instance lock during eswitch_mode callbacks
Date: Thu, 17 Mar 2022 09:52:10 +0200 [thread overview]
Message-ID: <YjLoqpwsgJdXeIGq@unreal> (raw)
In-Reply-To: <20220317042023.1470039-6-kuba@kernel.org>
On Wed, Mar 16, 2022 at 09:20:23PM -0700, Jakub Kicinski wrote:
> Make the devlink core hold the instance lock during eswitch_mode
> callbacks. Cheat in case of mlx5 (see the cover letter).
And this is one the main difference between your and mine proposals/solutions.
I didn't want to cheat as it doesn't help to the end goal - remove devlink_mutex.
Can you please change the comments in mlx5 to be more direct?
"/* TODO: convert the driver to devl_* */"
->
"/* FIXME: devl_unlock() followed by devl_lock() inside driver callback
* never correct and prone to races. Never repeat this pattern.
*
* This code MUST be fixed before removing devlink_mutex as it is safe
* to do only because of that mutex.
*/"
Something like that.
The code is correct, but like I said before, I don't like the direction.
I expect that this anti-pattern is going to be copy/pasted very soon.
Thanks,
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
next prev parent reply other threads:[~2022-03-17 7:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-17 4:20 [PATCH net-next 0/5] devlink: hold the instance lock in eswitch callbacks Jakub Kicinski
2022-03-17 4:20 ` [PATCH net-next 1/5] bnxt: use the devlink instance lock to protect sriov Jakub Kicinski
[not found] ` <CACKFLi=O4ffBLgP=Xi_CFzwpFVc+zGRH4pmZ15h_YP-imzNpvw@mail.gmail.com>
2022-03-17 17:45 ` Sriharsha Basavapatna
2022-03-17 18:19 ` Jakub Kicinski
2022-03-17 19:24 ` Sriharsha Basavapatna
2022-03-17 4:20 ` [PATCH net-next 2/5] devlink: add explicitly locked flavor of the rate node APIs Jakub Kicinski
2022-03-17 8:02 ` Jiri Pirko
2022-03-17 4:20 ` [PATCH net-next 3/5] netdevsim: replace port_list_lock with devlink instance lock Jakub Kicinski
2022-03-17 4:20 ` [PATCH net-next 4/5] netdevsim: replace vfs_lock " Jakub Kicinski
2022-03-17 4:20 ` [PATCH net-next 5/5] devlink: hold the instance lock during eswitch_mode callbacks Jakub Kicinski
2022-03-17 7:52 ` Leon Romanovsky [this message]
2022-03-17 15:41 ` Jakub Kicinski
2022-03-17 8:37 ` Jiri Pirko
2022-03-18 8:12 ` [PATCH net-next 0/5] devlink: hold the instance lock in eswitch callbacks Simon Horman
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=YjLoqpwsgJdXeIGq@unreal \
--to=leon@kernel.org \
--cc=davem@davemloft.net \
--cc=idosch@idosch.org \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@nvidia.com \
--cc=simon.horman@corigine.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).