public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Tariq Toukan <ttoukan.linux@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Emeel Hakim <ehakim@nvidia.com>,
	Eric Dumazet <edumazet@google.com>,
	linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
	Paolo Abeni <pabeni@redhat.com>, Raed Salem <raeds@nvidia.com>,
	Saeed Mahameed <saeedm@nvidia.com>,
	Tariq Toukan <tariqt@nvidia.com>
Subject: Re: [PATCH net] net/mlx5e: Cleanup MACsec uninitialization routine
Date: Thu, 13 Oct 2022 13:14:15 +0300	[thread overview]
Message-ID: <Y0fk9wD4CeS8vh1E@unreal> (raw)
In-Reply-To: <446abc60-b954-6c41-e6f6-62e0ff02c9e9@gmail.com>

On Thu, Oct 13, 2022 at 01:03:43PM +0300, Tariq Toukan wrote:
> 
> 
> On 10/13/2022 10:21 AM, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> > 
> > The mlx5e_macsec_cleanup() routine has pointer dereferencing if mlx5 device
> > doesn't support MACsec (priv->macsec will be NULL) together with useless
> > comment line, assignment and extra blank lines.
> > 
> > Fix everything in one patch.
> > 
> > Fixes: 1f53da676439 ("net/mlx5e: Create advanced steering operation (ASO) object for MACsec")
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> >   .../net/ethernet/mellanox/mlx5/core/en_accel/macsec.c | 11 +----------
> >   1 file changed, 1 insertion(+), 10 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c
> > index 41970067917b..4331235b21ee 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c
> > @@ -1846,25 +1846,16 @@ int mlx5e_macsec_init(struct mlx5e_priv *priv)
> >   void mlx5e_macsec_cleanup(struct mlx5e_priv *priv)
> >   {
> >   	struct mlx5e_macsec *macsec = priv->macsec;
> > -	struct mlx5_core_dev *mdev = macsec->mdev;
> > +	struct mlx5_core_dev *mdev = priv->mdev;
> 
> simply defer the mdev calculation to be after the early return, trying to
> keep this macsec function as independent as possible.

It is done to keep _cleanup symmetrical to _init one. The function
should operate on same priv->mdev as was used there without any relation
to macsec->mdev. Of course, it is the same pointer, but it is better to have
same code.

> 
> >   	if (!macsec)
> >   		return;
> >   	mlx5_notifier_unregister(mdev, &macsec->nb);
> > -
> >   	mlx5e_macsec_fs_cleanup(macsec->macsec_fs);
> > -
> > -	/* Cleanup workqueue */
> >   	destroy_workqueue(macsec->wq);
> > -
> >   	mlx5e_macsec_aso_cleanup(&macsec->aso, mdev);
> > -
> > -	priv->macsec = NULL;
> > -
> 
> Why remove this assignment?
> 
> It protects against accessing freed memory, for instance when querying the
> macsec stats, see
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec_stats.c

You can't and shouldn't access anything related to MACsec after call to
mlx5e_macsec_cleanup(). If you do so, you are already in trouble as you
don't have any locking protection from stat access and cleanup.

So no, it doesn't protect from accessing freed memory. It is just
anti-pattern of hiding bugs related to unlocked concurrent accesses
and wrong release flows. Don't do it.

Thanks

> 
> >   	rhashtable_destroy(&macsec->sci_hash);
> > -
> >   	mutex_destroy(&macsec->lock);
> > -
> >   	kfree(macsec);
> >   }

  reply	other threads:[~2022-10-13 10:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-13  7:21 [PATCH net] net/mlx5e: Cleanup MACsec uninitialization routine Leon Romanovsky
2022-10-13 10:03 ` Tariq Toukan
2022-10-13 10:14   ` Leon Romanovsky [this message]
2022-10-18 10:26 ` Leon Romanovsky
2022-10-18 18:04   ` Jakub Kicinski

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=Y0fk9wD4CeS8vh1E@unreal \
    --to=leon@kernel.org \
    --cc=dan.carpenter@oracle.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ehakim@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=raeds@nvidia.com \
    --cc=saeedm@nvidia.com \
    --cc=tariqt@nvidia.com \
    --cc=ttoukan.linux@gmail.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