From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Andy Gospodarek <andrew.gospodarek@broadcom.com>,
Aron Silverton <aron.silverton@oracle.com>,
Dan Williams <dan.j.williams@intel.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Dave Jiang <dave.jiang@intel.com>,
David Ahern <dsahern@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
Christoph Hellwig <hch@infradead.org>,
Itay Avraham <itayavr@nvidia.com>, Jiri Pirko <jiri@nvidia.com>,
Jakub Kicinski <kuba@kernel.org>,
Leonid Bloch <lbloch@nvidia.com>,
Leon Romanovsky <leonro@nvidia.com>, <linux-cxl@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, Saeed Mahameed <saeedm@nvidia.com>
Subject: Re: [PATCH v3 02/10] fwctl: Basic ioctl dispatch for the character device
Date: Fri, 23 Aug 2024 15:02:07 +0100 [thread overview]
Message-ID: <20240823150207.000000e9@Huawei.com> (raw)
In-Reply-To: <2-v3-960f17f90f17+516-fwctl_jgg@nvidia.com>
On Wed, 21 Aug 2024 15:10:54 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:
> Each file descriptor gets a chunk of per-FD driver specific context that
> allows the driver to attach a device specific struct to. The core code
> takes care of the memory lifetime for this structure.
>
> The ioctl dispatch and design is based on what was built for iommufd. The
> ioctls have a struct which has a combined in/out behavior with a typical
> 'zero pad' scheme for future extension and backwards compatibility.
>
> Like iommufd some shared logic does most of the ioctl marshalling and
> compatibility work and tables diatches to some function pointers for
> each unique iotcl.
>
> This approach has proven to work quite well in the iommufd and rdma
> subsystems.
>
> Allocate an ioctl number space for the subsystem.
>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Hi Jason,
A few minor things inline, but all trivial so
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> diff --git a/drivers/fwctl/main.c b/drivers/fwctl/main.c
> index 7f3e7713d0e6e9..f2e30ffc1e0cb5 100644
> --- a/drivers/fwctl/main.c
> +++ b/drivers/fwctl/main.c
>
> @@ -71,6 +183,9 @@ _alloc_device(struct device *parent, const struct fwctl_ops *ops, size_t size)
>
> fwctl->dev.class = &fwctl_class;
> fwctl->dev.parent = parent;
> + init_rwsem(&fwctl->registration_lock);
> + mutex_init(&fwctl->uctx_list_lock);
If the ida_alloc_max() fails,I don't think you destroy the mutex as the
device isn't yet initialized / put in the error path.
Whilst i find it hard to care, it's nice to always destroy mutex, or not do it at all.
Feels odd to only do it if things go well.
> + INIT_LIST_HEAD(&fwctl->uctx_list);
>
> devnum = ida_alloc_max(&fwctl_ida, FWCTL_MAX_DEVICES - 1, GFP_KERNEL);
> if (devnum < 0)
> @@ -127,6 +242,10 @@ EXPORT_SYMBOL_NS_GPL(fwctl_register, FWCTL);
> * Undoes fwctl_register(). On return no driver ops will be called. The
> * caller must still call fwctl_put() to free the fwctl.
> *
> + * Unregister will return even if userspace still has file descriptors open.
> + * This will call ops->close_uctx() on any open FDs and after return no driver
> + * op will be called. The FDs remain open but all fops will return -ENODEV.
> + *
> * The design of fwctl allows this sort of disassociation of the driver from the
> * subsystem primarily by keeping memory allocations owned by the core subsytem.
> * The fwctl_device and fwctl_uctx can both be freed without requiring a driver
> @@ -134,7 +253,23 @@ EXPORT_SYMBOL_NS_GPL(fwctl_register, FWCTL);
> */
> void fwctl_unregister(struct fwctl_device *fwctl)
> {
> + struct fwctl_uctx *uctx;
> +
> cdev_device_del(&fwctl->cdev, &fwctl->dev);
> +
> + /* Disable and free the driver's resources for any still open FDs. */
> + guard(rwsem_write)(&fwctl->registration_lock);
> + guard(mutex)(&fwctl->uctx_list_lock);
> + while ((uctx = list_first_entry_or_null(&fwctl->uctx_list,
> + struct fwctl_uctx,
> + uctx_list_entry)))
> + fwctl_destroy_uctx(uctx);
> +
> + /*
> + * The driver module may unload after this returns, the op pointer will
> + * not be valid.
> + */
> + fwctl->ops = NULL;
> }
> EXPORT_SYMBOL_NS_GPL(fwctl_unregister, FWCTL);
>
> diff --git a/include/linux/fwctl.h b/include/linux/fwctl.h
> index 68ac2d5ab87481..ca4245825e91bf 100644
> --- a/include/linux/fwctl.h
> +++ b/include/linux/fwctl.h
>
> /**
> @@ -26,6 +49,15 @@ struct fwctl_device {
> struct device dev;
> /* private: */
> struct cdev cdev;
> +
> + /*
> + * Protect ops, held for write when ops becomes NULL during unregister,
> + * held for read whenver ops is loaded or an ops function is running.
> + */
> + struct rw_semaphore registration_lock;
Maybe move down to just above ops?
> + /* Protect uctx_list */
> + struct mutex uctx_list_lock;
> + struct list_head uctx_list;
> const struct fwctl_ops *ops;
> };
> diff --git a/include/uapi/fwctl/fwctl.h b/include/uapi/fwctl/fwctl.h
> new file mode 100644
> index 00000000000000..22fa750d7e8184
> --- /dev/null
> +++ b/include/uapi/fwctl/fwctl.h
> @@ -0,0 +1,38 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/* Copyright (c) 2024, NVIDIA CORPORATION & AFFILIATES.
> + */
> +#ifndef _UAPI_FWCTL_H
> +#define _UAPI_FWCTL_H
> +
> +#define FWCTL_TYPE 0x9A
> +
> +/**
> + * DOC: General ioctl format
> + *
> + * The ioctl interface follows a general format to allow for extensibility. Each
> + * ioctl is passed in a structure pointer as the argument providing the size of
Pedantic Englishman time:
passed a structure pointer
(otherwise I read that as passing an ioctl in a pointer which is weird).
> + * the structure in the first u32. The kernel checks that any structure space
...
next prev parent reply other threads:[~2024-08-23 14:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-21 18:10 [PATCH v3 00/10] Introduce fwctl subystem Jason Gunthorpe
2024-08-21 18:10 ` [PATCH v3 01/10] fwctl: Add basic structure for a class subsystem with a cdev Jason Gunthorpe
2024-08-23 13:48 ` Jonathan Cameron
2024-08-21 18:10 ` [PATCH v3 02/10] fwctl: Basic ioctl dispatch for the character device Jason Gunthorpe
2024-08-23 14:02 ` Jonathan Cameron [this message]
2024-08-27 14:56 ` Jason Gunthorpe
2024-08-21 18:10 ` [PATCH v3 03/10] fwctl: FWCTL_INFO to return basic information about the device Jason Gunthorpe
2024-08-23 14:14 ` Jonathan Cameron
2024-08-27 14:47 ` Jason Gunthorpe
2024-08-27 14:55 ` Andy Gospodarek
2024-08-21 18:10 ` [PATCH v3 04/10] taint: Add TAINT_FWCTL Jason Gunthorpe
2024-08-21 23:35 ` Greg Kroah-Hartman
2024-08-22 15:34 ` Jason Gunthorpe
2024-08-21 18:10 ` [PATCH v3 05/10] fwctl: FWCTL_RPC to execute a Remote Procedure Call to device firmware Jason Gunthorpe
2024-08-21 23:49 ` Jakub Kicinski
2024-08-22 0:14 ` Jason Gunthorpe
2024-08-22 0:30 ` Jakub Kicinski
2024-08-27 15:27 ` Jason Gunthorpe
2024-08-23 14:23 ` Jonathan Cameron
2024-08-21 18:10 ` [PATCH v3 06/10] fwctl: Add documentation Jason Gunthorpe
2024-08-23 14:35 ` Jonathan Cameron
2024-08-27 14:58 ` Jason Gunthorpe
2024-08-21 18:10 ` [PATCH v3 07/10] fwctl/mlx5: Support for communicating with mlx5 fw Jason Gunthorpe
2024-08-23 14:48 ` Jonathan Cameron
2024-08-27 15:07 ` Jason Gunthorpe
2024-08-21 18:11 ` [PATCH v3 08/10] mlx5: Create an auxiliary device for fwctl_mlx5 Jason Gunthorpe
2024-08-21 18:11 ` [PATCH v3 09/10] fwctl/cxl: Add driver for CXL mailbox for handling CXL features commands (RFC) Jason Gunthorpe
2024-08-21 18:11 ` [PATCH v3 10/10] cxl: Create an auxiliary device for fwctl_cxl Jason Gunthorpe
2024-09-13 22:39 ` [PATCH v3 00/10] Introduce fwctl subystem Dave Jiang
2024-09-16 7:54 ` Leon Romanovsky
2024-09-17 20:59 ` Dave Jiang
2024-12-05 22:28 ` Shannon Nelson
2024-12-05 23:58 ` 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=20240823150207.000000e9@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=aron.silverton@oracle.com \
--cc=dan.j.williams@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dave.jiang@intel.com \
--cc=dsahern@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--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-cxl@vger.kernel.org \
--cc=linux-rdma@vger.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 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.