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>,
Andy Gospodarek <gospo@broadcom.com>,
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>, <netdev@vger.kernel.org>,
Saeed Mahameed <saeedm@nvidia.com>,
"Nelson, Shannon" <shannon.nelson@amd.com>
Subject: Re: [PATCH v4 02/10] fwctl: Basic ioctl dispatch for the character device
Date: Fri, 7 Feb 2025 12:59:15 +0000 [thread overview]
Message-ID: <20250207125915.000079e4@huawei.com> (raw)
In-Reply-To: <2-v4-0cf4ec3b8143+4995-fwctl_jgg@nvidia.com>
On Thu, 6 Feb 2025 20:13:24 -0400
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.
>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Hi Jason,
Fresh read through given it's been a while.
A few really trivial things inline + one passing comment on a future
entertaining corner.
Jonathan
> M: Sebastian Reichel <sre@kernel.org>
> diff --git a/drivers/fwctl/main.c b/drivers/fwctl/main.c
> index 34946bdc3bf3d7..d561deaf2b86d8 100644
> --- a/drivers/fwctl/main.c
> +++ b/drivers/fwctl/main.c
> static int fwctl_fops_release(struct inode *inode, struct file *filp)
> {
> - struct fwctl_device *fwctl = filp->private_data;
> + struct fwctl_uctx *uctx = filp->private_data;
> + struct fwctl_device *fwctl = uctx->fwctl;
>
> + scoped_guard(rwsem_read, &fwctl->registration_lock) {
> + /*
> + * fwctl_unregister() has already removed the driver and
> + * destroyed the uctx.
Comment is a little odd given it is I think referring to why
the code that follows wouldn't run. Perhaps just add a 'may'
fwctl_unregister() may have already removed the driver and destroyed
the uctx.
> + */
> + if (fwctl->ops) {
> + guard(mutex)(&fwctl->uctx_list_lock);
> + fwctl_destroy_uctx(uctx);
> + }
> + }
> +
> + kfree(uctx);
> fwctl_put(fwctl);
> return 0;
> }
>
> @@ -71,14 +183,17 @@ _alloc_device(struct device *parent, const struct fwctl_ops *ops, size_t size)
> if (!fwctl)
> return NULL;
>
> - fwctl->dev.class = &fwctl_class;
> - fwctl->dev.parent = parent;
> -
> devnum = ida_alloc_max(&fwctl_ida, FWCTL_MAX_DEVICES - 1, GFP_KERNEL);
> if (devnum < 0)
> return NULL;
> fwctl->dev.devt = fwctl_dev + devnum;
>
> + fwctl->dev.class = &fwctl_class;
> + fwctl->dev.parent = parent;
Shunt this move back to previous patch?
> + init_rwsem(&fwctl->registration_lock);
> + mutex_init(&fwctl->uctx_list_lock);
> + INIT_LIST_HEAD(&fwctl->uctx_list);
> +
> device_initialize(&fwctl->dev);
> return_ptr(fwctl);
> }
> diff --git a/include/linux/fwctl.h b/include/linux/fwctl.h
> index 68ac2d5ab87481..93b470efb9dbc3 100644
> --- a/include/linux/fwctl.h
> +++ b/include/linux/fwctl.h
> @@ -11,7 +11,30 @@
> struct fwctl_device;
> struct fwctl_uctx;
>
> +/**
> + * struct fwctl_ops - Driver provided operations
> + *
> + * fwctl_unregister() will wait until all excuting ops are completed before it
> + * returns. Drivers should be mindful to not let their ops run for too long as
> + * it will block device hot unplug and module unloading.
A passing comment on this. Seems likely that at somepoint we'll want an
abort op to enable cancelling if the particular driver supports it
(abort background command in CXL). Anyhow, problem for another day.
> + */
> struct fwctl_ops {
> + /**
> + * @uctx_size: The size of the fwctl_uctx struct to allocate. The first
> + * bytes of this memory will be a fwctl_uctx. The driver can use the
> + * remaining bytes as its private memory.
> + */
> + size_t uctx_size;
> + /**
> + * @open_uctx: Called when a file descriptor is opened before the uctx
> + * is ever used.
> + */
> + int (*open_uctx)(struct fwctl_uctx *uctx);
> + /**
> + * @close_uctx: Called when the uctx is destroyed, usually when the FD
> + * is closed.
> + */
> + void (*close_uctx)(struct fwctl_uctx *uctx);
> };
next prev parent reply other threads:[~2025-02-07 12:59 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-07 0:13 [PATCH v4 00/10] Introduce fwctl subystem Jason Gunthorpe
2025-02-07 0:13 ` [PATCH v4 01/10] fwctl: Add basic structure for a class subsystem with a cdev Jason Gunthorpe
2025-02-07 23:32 ` Dan Williams
2025-02-07 23:55 ` Jason Gunthorpe
2025-02-08 0:08 ` Dave Jiang
2025-02-07 0:13 ` [PATCH v4 02/10] fwctl: Basic ioctl dispatch for the character device Jason Gunthorpe
2025-02-07 12:59 ` Jonathan Cameron [this message]
2025-02-07 13:52 ` Jason Gunthorpe
2025-02-08 0:16 ` Dave Jiang
2025-02-10 15:24 ` Jason Gunthorpe
2025-02-13 12:42 ` Przemek Kitszel
2025-02-13 18:52 ` Jason Gunthorpe
2025-02-07 0:13 ` [PATCH v4 03/10] fwctl: FWCTL_INFO to return basic information about the device Jason Gunthorpe
2025-02-07 13:06 ` Jonathan Cameron
2025-02-07 14:23 ` Jason Gunthorpe
2025-02-08 0:21 ` Dave Jiang
2025-02-07 0:13 ` [PATCH v4 04/10] taint: Add TAINT_FWCTL Jason Gunthorpe
2025-02-07 13:09 ` Jonathan Cameron
2025-02-08 0:24 ` Dave Jiang
2025-02-07 0:13 ` [PATCH v4 05/10] fwctl: FWCTL_RPC to execute a Remote Procedure Call to device firmware Jason Gunthorpe
2025-02-08 0:28 ` Dave Jiang
2025-02-07 0:13 ` [PATCH v4 06/10] fwctl: Add documentation Jason Gunthorpe
2025-02-07 14:42 ` Jonathan Cameron
2025-02-10 15:17 ` Jason Gunthorpe
2025-02-08 0:40 ` Dave Jiang
2025-02-07 0:13 ` [PATCH v4 07/10] fwctl/mlx5: Support for communicating with mlx5 fw Jason Gunthorpe
2025-02-13 13:19 ` Przemek Kitszel
2025-02-13 14:25 ` Leon Romanovsky
2025-02-13 19:18 ` Jason Gunthorpe
2025-02-07 0:13 ` [PATCH v4 08/10] mlx5: Create an auxiliary device for fwctl_mlx5 Jason Gunthorpe
2025-02-07 0:13 ` [PATCH v4 09/10] fwctl/bnxt: Support communicating with bnxt fw Jason Gunthorpe
2025-02-07 14:59 ` Jonathan Cameron
2025-02-07 15:03 ` Jason Gunthorpe
2025-02-07 0:13 ` [PATCH v4 10/10] bnxt: Create an auxiliary device for fwctl_bnxt Jason Gunthorpe
2025-02-07 0:44 ` Jakub Kicinski
2025-02-07 3:17 ` Andy Gospodarek
2025-02-07 12:46 ` Jason Gunthorpe
2025-02-07 15:36 ` Jakub Kicinski
2025-02-07 20:25 ` Saeed Mahameed
2025-02-07 21:51 ` Jakub Kicinski
2025-02-08 1:10 ` Saeed Mahameed
2025-02-08 1:16 ` Jason Gunthorpe
2025-02-08 3:24 ` Andy Gospodarek
2025-02-11 1:04 ` Jakub Kicinski
2025-02-11 7:55 ` Leon Romanovsky
2025-02-11 14:27 ` Andy Gospodarek
2025-02-12 14:20 ` Leon Romanovsky
2025-02-11 18:36 ` Nelson, Shannon
2025-02-12 13:22 ` Leon Romanovsky
2025-02-14 1:03 ` Saeed Mahameed
2025-02-17 12:49 ` Jiri Pirko
2025-02-17 19:02 ` Leon Romanovsky
2025-02-11 16:24 ` David Ahern
2025-02-18 20:05 ` Jason Gunthorpe
2025-02-18 21:42 ` David Ahern
2025-02-18 23:31 ` Jakub Kicinski
2025-02-24 22:34 ` Saeed Mahameed
2025-02-07 23:29 ` Andy Gospodarek
2025-02-08 0:08 ` Jakub Kicinski
2025-02-07 21:41 ` [PATCH v4 00/10] Introduce fwctl subystem Dan Williams
2025-02-07 21:58 ` Dave Jiang
2025-02-11 9:33 ` Jonathan Cameron
2025-02-13 17:55 ` Jason Gunthorpe
2025-02-13 17:52 ` Jason Gunthorpe
2025-02-12 22:21 ` Zhu Yanjun
2025-02-13 2:30 ` Nelson, Shannon
2025-02-13 18:02 ` 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=20250207125915.000079e4@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=gospo@broadcom.com \
--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=netdev@vger.kernel.org \
--cc=saeedm@nvidia.com \
--cc=shannon.nelson@amd.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).