public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Saeed Mahameed <saeed@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	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 15:41:54 +0000	[thread overview]
Message-ID: <2023112951-civil-risotto-50dc@gregkh> (raw)
In-Reply-To: <20231129130200.GV436702@nvidia.com>

On Wed, Nov 29, 2023 at 09:02:00AM -0400, Jason Gunthorpe wrote:
> On Wed, Nov 29, 2023 at 09:20:32AM +0000, Greg Kroah-Hartman wrote:
> > 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.
> 
> This second refcount is hidden well:
> 
> struct miscdevice {
> 	int minor;
> 	const char *name;
> 	const struct file_operations *fops;
> 	struct list_head list;
> 	struct device *parent;
> 	struct device *this_device;
> 	const struct attribute_group **groups;
> 	const char *nodename;
> 	umode_t mode;
> };

Ugh, you are right, I was wrong, there is no reference count here, using
a miscdevice _requires_ you to have a separate reference count, like you
all did.  My fault.

> > > 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.
> 
> A normal mutex would make the entire ioctl interface single threaded,
> this is not desirable.

Why not?  It's an ioctl for a single device, surely this isn't
performance criticial.  And then only grab it when needed, on
read/write/ioctl path it shouldn't be needed at all due to the proper
reference counting of the structures.  Only on open/close, right?

And again, for a rw semaphore, benchmarks matter, often, if not almost
always, a normal mutex is faster for stuff like this.  If not, then a
benchmark will show it.

> > But before you do that, please see my other email about why not using
> > devlink for all of this instead.
> 
> We've been over this already, the devlink discussion is about some
> configuration stuff.

It was?  I see device-specific diagonostic data for the mlx5 driver
being exported through devlink today, that's not configuration.  Why not
just add more?

> It has never been suggested to cover the debug interface. This series
> is primarily about debug, the devlink thing is a distraction to main
> point.

For me it is the main point at the moment.  Please explain why devlink
does not work for the information that you have created a misc device
where you want an ioctl api instead, as I honestly do not understand.

thanks,

greg k-h

  reply	other threads:[~2023-11-29 15:42 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
2023-11-29 13:02         ` Jason Gunthorpe
2023-11-29 15:41           ` Greg Kroah-Hartman [this message]
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=2023112951-civil-risotto-50dc@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