From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Saeed Mahameed <saeed@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Jason Gunthorpe <jgg@nvidia.com>,
Leon Romanovsky <leonro@nvidia.com>, Jiri Pirko <jiri@nvidia.com>,
Leonid Bloch <lbloch@nvidia.com>,
Itay Avraham <itayavr@nvidia.com>,
Jakub Kicinski <kuba@kernel.org>,
linux-kernel@vger.kernel.org, Saeed Mahameed <saeedm@nvidia.com>
Subject: Re: [PATCH V3 2/5] misc: mlx5ctl: Add mlx5ctl misc driver
Date: Wed, 29 Nov 2023 09:20:32 +0000 [thread overview]
Message-ID: <2023112938-unhook-defiance-75ed@gregkh> (raw)
In-Reply-To: <ZWb_l7rC4QK8duU3@x130>
On Wed, Nov 29, 2023 at 01:08:39AM -0800, Saeed Mahameed wrote:
> On 27 Nov 18:59, Greg Kroah-Hartman wrote:
> > On Mon, Nov 20, 2023 at 11:06:16PM -0800, Saeed Mahameed wrote:
> > > +struct mlx5ctl_dev {
> > > + struct mlx5_core_dev *mdev;
> > > + struct miscdevice miscdev;
> > > + struct auxiliary_device *adev;
> > > + struct list_head fd_list;
> > > + spinlock_t fd_list_lock; /* protect list add/del */
> > > + struct rw_semaphore rw_lock;
> > > + struct kref refcount;
> >
> > You now have 2 different things that control the lifespan of this
> > structure. We really need some way to automatically check this so that
> > people don't keep making this same mistake, it happens all the time :(
> >
> > Please pick one structure (miscdevice) or the other (kref) to control
> > the lifespan, having 2 will just not work.
> >
>
> miscdevice doesn't handle the lifespan, open files will remain open even
> after the miscdevice was unregistered, hence we use the kref to defer the
> kfree until the last open file is closed.
miscdevice has a reference counter and a lifecycle, you can not have two
reference counted objects in the same structure and expect things to
work well.
> > Also, why a rw_semaphore? Only use those if you can prove with a
> > benchmark that it is actually faster, otherwise it's simpler to just use
> > a normal mutex (hint, you are changing the fields in the structure with
> > the read lock held, which feels very wrong, and so needs a LOT of
> > documentation, or just use a normal mutex...)
> >
>
> It is needed so we can protect against underlaying device unloading while
> miscdevice is active, we use rw semaphore since we don't care about
> synchronization between any of the fops, but we want to protect current
> active ioctls and fops from sudden mlx5ctl_remove (auxiliary_driver.remove)
> which can happen dynamically due to underlaying device removal.
Then use a normal mutex. Only use a rw lock if you can prove the
performance needs it as usually a rw lock is slower and more complex as
you then have to document stuff like:
> So here is the locking scheme:
>
> write_lock() : only on mlx5_ctl remove and mark the device is down
> via assigning NULL to mcdev->dev, to let all new readers abort and to wait
> for current readers to finish their task.
>
> read_lock(): used in all fops and ioctls, to make sure underlaying
> mlx5_core device is still active, and to prevent open files to access the
> device when miscdevice was already unregistered.
>
> I agree, this should've been documented in the code, I will add
> documentation.
Just make it simple and use a normal mutex please.
And fix up the reference counting, it shouldn't be this complex, it's
just a "simple" misc device driver :)
But before you do that, please see my other email about why not using
devlink for all of this instead.
thanks,
greg k-h
next prev parent reply other threads:[~2023-11-29 9:20 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 7:06 [PATCH V3 0/5] mlx5 ConnectX control misc driver Saeed Mahameed
2023-11-21 7:06 ` [PATCH V3 1/5] mlx5: Add aux dev for ctl interface Saeed Mahameed
2023-11-21 7:06 ` [PATCH V3 2/5] misc: mlx5ctl: Add mlx5ctl misc driver Saeed Mahameed
2023-11-27 13:36 ` Greg Kroah-Hartman
2023-11-27 14:40 ` Jason Gunthorpe
2023-11-27 15:51 ` Greg Kroah-Hartman
2023-11-27 16:17 ` Jason Gunthorpe
2023-11-27 18:27 ` Greg Kroah-Hartman
2023-11-27 19:26 ` Saeed Mahameed
2023-11-28 0:07 ` Jakub Kicinski
2023-11-28 4:46 ` David Ahern
2023-11-28 14:53 ` Jakub Kicinski
2023-11-28 16:24 ` Jason Gunthorpe
2023-11-28 16:44 ` Jakub Kicinski
2023-11-28 17:52 ` Jason Gunthorpe
2023-11-28 18:33 ` Jakub Kicinski
2023-11-28 19:55 ` Saeed Mahameed
2023-11-28 20:10 ` Saeed Mahameed
2023-11-29 9:08 ` Greg Kroah-Hartman
2023-12-04 21:37 ` Aron Silverton
2023-12-05 2:52 ` Jakub Kicinski
2023-12-05 17:11 ` Aron Silverton
2023-12-06 4:48 ` Jakub Kicinski
2023-12-07 15:54 ` David Ahern
2023-12-07 16:20 ` Jakub Kicinski
2023-12-07 16:41 ` Aron Silverton
2023-12-07 17:23 ` Jakub Kicinski
2023-12-07 18:06 ` Aron Silverton
2023-12-07 19:02 ` Saeed Mahameed
2023-12-08 5:29 ` Greg Kroah-Hartman
2023-12-08 13:34 ` Jason Gunthorpe
2023-12-08 5:27 ` Greg Kroah-Hartman
2023-12-08 12:52 ` Jason Gunthorpe
2023-12-07 18:54 ` Saeed Mahameed
2023-12-13 16:55 ` Christoph Hellwig
2023-11-28 19:31 ` Saeed Mahameed
2023-11-28 16:52 ` David Ahern
2023-11-27 18:59 ` Greg Kroah-Hartman
2023-11-29 9:08 ` Saeed Mahameed
2023-11-29 9:20 ` Greg Kroah-Hartman [this message]
2023-11-29 13:02 ` Jason Gunthorpe
2023-11-29 15:41 ` Greg Kroah-Hartman
2023-11-29 18:07 ` Jason Gunthorpe
2023-11-21 7:06 ` [PATCH V3 3/5] misc: mlx5ctl: Add info ioctl Saeed Mahameed
2023-11-27 19:09 ` Greg Kroah-Hartman
2023-11-27 20:39 ` Saeed Mahameed
2023-11-28 9:13 ` Greg Kroah-Hartman
2023-11-29 8:53 ` Saeed Mahameed
2023-11-21 7:06 ` [PATCH V3 4/5] misc: mlx5ctl: Add command rpc ioctl Saeed Mahameed
2023-11-21 7:06 ` [PATCH V3 5/5] misc: mlx5ctl: Add umem reg/unreg ioctl Saeed Mahameed
2023-11-21 20:44 ` Jakub Kicinski
2023-11-21 21:04 ` Saeed Mahameed
2023-11-21 22:10 ` Jakub Kicinski
2023-11-21 22:52 ` Saeed Mahameed
2023-11-21 22:18 ` David Ahern
2023-11-21 22:46 ` Saeed Mahameed
2023-11-21 23:46 ` Jason Gunthorpe
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=2023112938-unhook-defiance-75ed@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=itayavr@nvidia.com \
--cc=jgg@nvidia.com \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=lbloch@nvidia.com \
--cc=leonro@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=saeed@kernel.org \
--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).