From: Leon Romanovsky <leon@kernel.org>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: roid@nvidia.com, linux-rdma@vger.kernel.org,
Mark Bloch <markb@nvidia.com>, Saeed Mahameed <saeedm@nvidia.com>,
linux-netdev <netdev@vger.kernel.org>
Subject: Re: [bug report] net/mlx5: E-Switch, Protect changing mode while adding rules
Date: Tue, 24 May 2022 21:13:02 +0300 [thread overview]
Message-ID: <Yo0gLpMS7CuUII0D@unreal> (raw)
In-Reply-To: <YoH3ZVir5UZUgs3R@kili>
On Mon, May 16, 2022 at 10:04:05AM +0300, Dan Carpenter wrote:
> Hello Roi Dayan,
>
> The patch 7dc84de98bab: "net/mlx5: E-Switch, Protect changing mode
> while adding rules" from Sep 16, 2020, leads to the following Smatch
> static checker warning:
>
> drivers/net/ethernet/mellanox/mlx5/core/eswitch.c:2000 mlx5_esw_unlock()
> warn: inconsistent returns '&esw->mode_lock'.
>
> drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> 1996 void mlx5_esw_unlock(struct mlx5_eswitch *esw)
> 1997 {
> 1998 if (!mlx5_esw_allowed(esw))
> 1999 return;
>
> Smatch is complaining because how will the caller know if we dropped
> the lock or not. I thought, "Hm. I guess the lock function has a
> similar check? Although, how does that work that mlx5_esw_allowed()
> means that it doesn't need locking?"
>
> But then when I looked at the lock function, mlx5_esw_try_lock(), and it
> does *NOT* have a similar check. This probably works because it's
> checked in different layers and this is just a duplicative (layering
> violation) check which is ugly but harmless.
Your analysis is correct and I agree with you, the check should be removed.
However the "problematic" commit is ec2fa47d7b98 ("net/mlx5: Lag, use lag lock"),
where mlx5_esw_lock() was removed.
Thanks
>
> --> 2000 up_write(&esw->mode_lock);
> 2001 }
>
> regards,
> dan carpenter
parent reply other threads:[~2022-05-24 18:13 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <YoH3ZVir5UZUgs3R@kili>]
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=Yo0gLpMS7CuUII0D@unreal \
--to=leon@kernel.org \
--cc=dan.carpenter@oracle.com \
--cc=linux-rdma@vger.kernel.org \
--cc=markb@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=roid@nvidia.com \
--cc=saeedm@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).