All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Leon Romanovsky <leon@kernel.org>, Jason Gunthorpe <jgg@mellanox.com>
Cc: RDMA mailing list <linux-rdma@vger.kernel.org>,
	Saeed Mahameed <saeedm@mellanox.com>
Subject: Re: [PATCH rdma-rc] RDMA/mlx5: Release locks during notifier unregister
Date: Wed, 31 Jul 2019 14:51:42 -0400	[thread overview]
Message-ID: <805ad5c2714ad2fb4c9b92eb99a256e8998334f9.camel@redhat.com> (raw)
In-Reply-To: <20190731180124.GE4832@mtr-leonro.mtl.com>

[-- Attachment #1: Type: text/plain, Size: 2799 bytes --]

On Wed, 2019-07-31 at 21:01 +0300, Leon Romanovsky wrote:
> On Wed, Jul 31, 2019 at 05:22:19PM +0000, Jason Gunthorpe wrote:
> > On Wed, Jul 31, 2019 at 08:09:44PM +0300, Leon Romanovsky wrote:
> > > On Wed, Jul 31, 2019 at 05:00:59PM +0000, Jason Gunthorpe wrote:
> > > > On Wed, Jul 31, 2019 at 12:22:44PM -0400, Doug Ledford wrote:
> > > > > > diff --git a/drivers/infiniband/hw/mlx5/main.c
> > > > > > b/drivers/infiniband/hw/mlx5/main.c
> > > > > > index c2a5780cb394..e12a4404096b 100644
> > > > > > +++ b/drivers/infiniband/hw/mlx5/main.c
> > > > > > @@ -5802,13 +5802,12 @@ static void
> > > > > > mlx5_ib_unbind_slave_port(struct
> > > > > > mlx5_ib_dev *ibdev,
> > > > > >  		return;
> > > > > >  	}
> > > > > > 
> > > > > > -	if (mpi->mdev_events.notifier_call)
> > > > > > -		mlx5_notifier_unregister(mpi->mdev, &mpi-
> > > > > > >mdev_events);
> > > > > > -	mpi->mdev_events.notifier_call = NULL;
> > > > > > -
> > > > > >  	mpi->ibdev = NULL;
> > > > > > 
> > > > > >  	spin_unlock(&port->mp.mpi_lock);
> > > > > > +	if (mpi->mdev_events.notifier_call)
> > > > > > +		mlx5_notifier_unregister(mpi->mdev, &mpi-
> > > > > > >mdev_events);
> > > > > > +	mpi->mdev_events.notifier_call = NULL;
> > > > > 
> > > > > I can see where this fixes the problem at hand, but this gives
> > > > > the
> > > > > appearance of creating a new race.  Doing a
> > > > > check/unregister/set-null
> > > > > series outside of any locks is a red flag to someone
> > > > > investigating the
> > > > > code.  You should at least make note of the fact that calling
> > > > > unregister
> > > > > more than once is safe.  If you're fine with it, I can add a
> > > > > comment and
> > > > > take the patch, or you can resubmit.
> > > > 
> > > > Mucking about notifier_call like that is gross anyhow, maybe
> > > > better to
> > > > delete it entirely.
> > > 
> > > What do you propose to delete?
> > 
> > The 'mpi->mdev_events.notifier_call = NULL;' and 'if
> > (mpi->mdev_events.notifier_call)'
> > 
> > Once it leaves the lock it stops doing anything useful.
> > 
> > If you need it, then we can't drop the lock, if you don't, it is
> > just
> > dead code, delete it.
> 
> This specific notifier_call is protected outside
> of mlx5_ib_unbind_slave_port() by mlx5_ib_multiport_mutex and NULL
> check
> is needed to ensure single call to mlx5_notifier_unregister, because
> calls to mlx5_ib_unbind_slave_port() will be serialized.

But looking at the code, it doesn't appear mlx5_notifier_unregister
requires there to only be a single call.  It's safe to call it multiple
times for the same notifier.

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-07-31 18:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-31  8:38 [PATCH rdma-rc] RDMA/mlx5: Release locks during notifier unregister Leon Romanovsky
2019-07-31 16:22 ` Doug Ledford
2019-07-31 17:00   ` Jason Gunthorpe
2019-07-31 17:09     ` Leon Romanovsky
2019-07-31 17:22       ` Jason Gunthorpe
2019-07-31 18:01         ` Leon Romanovsky
2019-07-31 18:51           ` Doug Ledford [this message]
2019-08-01  8:22             ` Leon Romanovsky
2019-07-31 19:55           ` Jason Gunthorpe
2019-08-01  8:27             ` Leon Romanovsky
2019-08-01 12:00               ` Jason Gunthorpe
2019-08-01 12:08                 ` Leon Romanovsky
2019-08-01 14:16                   ` Doug Ledford
2019-08-01 15:59                     ` Leon Romanovsky
2019-08-01 16:11                       ` Doug Ledford
2019-08-01 16:20                         ` Jason Gunthorpe
2019-08-01 16:40                           ` Doug Ledford
2019-08-01 16:43                             ` Jason Gunthorpe
2019-08-01 16:50                               ` Doug Ledford
2019-08-01 17:31                                 ` Leon Romanovsky
2019-08-01 16:23                         ` Leon Romanovsky
2019-08-01 16:42                           ` Doug Ledford
2019-08-01 17:33                             ` Leon Romanovsky
2019-08-01 20:09                               ` Doug Ledford

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=805ad5c2714ad2fb4c9b92eb99a256e8998334f9.camel@redhat.com \
    --to=dledford@redhat.com \
    --cc=jgg@mellanox.com \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=saeedm@mellanox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.