From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Leon Romanovsky <leon@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Itay Avraham <itayavr@nvidia.com>,
Jakub Kicinski <kuba@kernel.org>, <linux-doc@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, <netdev@vger.kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Saeed Mahameed <saeedm@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>,
Andy Gospodarek <andrew.gospodarek@broadcom.com>,
Aron Silverton <aron.silverton@oracle.com>,
Dan Williams <dan.j.williams@intel.com>,
"David Ahern" <dsahern@kernel.org>,
Christoph Hellwig <hch@infradead.org>,
"Jiri Pirko" <jiri@nvidia.com>, Leonid Bloch <lbloch@nvidia.com>,
<linux-cxl@vger.kernel.org>, <patches@lists.linux.dev>
Subject: Re: [PATCH 1/8] fwctl: Add basic structure for a class subsystem with a cdev
Date: Tue, 4 Jun 2024 18:05:55 +0100 [thread overview]
Message-ID: <20240604180555.000063c2@Huawei.com> (raw)
In-Reply-To: <20240604155009.GJ19897@nvidia.com>
On Tue, 4 Jun 2024 12:50:09 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:
> On Tue, Jun 04, 2024 at 12:32:19PM +0300, Leon Romanovsky wrote:
> > > +static struct fwctl_device *
> > > +_alloc_device(struct device *parent, const struct fwctl_ops *ops, size_t size)
> > > +{
> > > + struct fwctl_device *fwctl __free(kfree) = kzalloc(size, GFP_KERNEL);
> > > +
> > > + if (!fwctl)
> > > + return NULL;
> >
> > <...>
> >
> > > +/* Drivers use the fwctl_alloc_device() wrapper */
> > > +struct fwctl_device *_fwctl_alloc_device(struct device *parent,
> > > + const struct fwctl_ops *ops,
> > > + size_t size)
> > > +{
> > > + struct fwctl_device *fwctl __free(fwctl) =
> > > + _alloc_device(parent, ops, size);
> >
> > I'm not a big fan of cleanup.h pattern as it hides important to me
> > information about memory object lifetime and by "solving" one class of
> > problems it creates another one.
>
> I'm trying it here. One of the most common bugs I end up fixing is
> error unwind and cleanup.h has successfully removed all of it. Let's
> find out, others thought it was a good idea to add the infrastructure.
>
> One thing that seems clear in my work here is that you should not use
> cleanup.h if you don't have simple memory lifetime, like the above
> case where the memory is freed if the function fails.
>
> > You didn't check if fwctl is NULL before using it.
>
> Oops, yes
>
> > > + int devnum;
> > > +
> > > + devnum = ida_alloc_max(&fwctl_ida, FWCTL_MAX_DEVICES - 1, GFP_KERNEL);
> > > + if (devnum < 0)
> > > + return NULL;
> > > + fwctl->dev.devt = fwctl_dev + devnum;
> > > +
> > > + cdev_init(&fwctl->cdev, &fwctl_fops);
> > > + fwctl->cdev.owner = THIS_MODULE;
> > > +
> > > + if (dev_set_name(&fwctl->dev, "fwctl%d", fwctl->dev.devt - fwctl_dev))
> >
> > Did you miss ida_free() here?
>
> No, the put_device() does it in the release function. The __free
> always calls fwctl_put()/put_device() on failure, and within all
> functions except _alloc_device() the put_device() is the correct way
> to free this memory.
The conditional handling of the ida having been allocated or not is a bit ugly
as I think it's just papering over this corner case.
Can fwctl_dev and devnum both be zero? In practice no, but is that guaranteed
for all time? Maybe...
We got some kick back from Linus a while back in CXL and the outcome was
a few more helpers rather than too much cleverness in the use of __free.
Trick for this is often to define a small function that allocates both the
ida and the device. With in that micro function handle the one error path
or if you only have two things to do, you can use __free() for the allocation.
Something like
static struct fwctl_device *__alloc_device_and_devt(sizet_t size)
{
struct fw_ctl_device *fwctl;
int devnum;
fwctl = ida_alloc_max(&fwct ...);
if (!fwctl)
return NULL;
devnum = ida_alloc_max(&fwct ...);
if (devnum < 0) {
kfree(fwctl);
return NULL;
}
fwctl->dev.devt = fwctl_Ddev + devnum;
reutrn fwctl;
}
Then call device_initialize() on the returned structure ->dev as you know
you ida and the containing structure are both in a state where the put_device()
call doesn't need conditions on 'how initialized' it is.
Still, maybe the ugly is fine.
>
> Thanks,
> Jason
>
>
next prev parent reply other threads:[~2024-06-04 17:06 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 15:53 [PATCH 0/8] Introduce fwctl subystem Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 1/8] fwctl: Add basic structure for a class subsystem with a cdev Jason Gunthorpe
2024-06-04 9:32 ` Leon Romanovsky
2024-06-04 15:50 ` Jason Gunthorpe
2024-06-04 17:05 ` Jonathan Cameron [this message]
2024-06-04 18:52 ` Jason Gunthorpe
2024-06-05 11:08 ` Jonathan Cameron
2024-06-04 16:42 ` Randy Dunlap
2024-06-04 16:44 ` Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 2/8] fwctl: Basic ioctl dispatch for the character device Jason Gunthorpe
2024-06-04 12:16 ` Zhu Yanjun
2024-06-04 12:22 ` Leon Romanovsky
2024-06-04 16:50 ` Jonathan Cameron
2024-06-04 16:58 ` Jason Gunthorpe
2024-06-05 11:07 ` Jonathan Cameron
2024-06-05 18:27 ` Jason Gunthorpe
2024-06-06 13:34 ` Jonathan Cameron
2024-06-06 15:37 ` Randy Dunlap
2024-06-05 15:42 ` Przemek Kitszel
2024-06-05 15:49 ` Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 3/8] fwctl: FWCTL_INFO to return basic information about the device Jason Gunthorpe
2024-06-13 23:32 ` Dave Jiang
2024-06-13 23:40 ` Jason Gunthorpe
2024-06-14 16:37 ` Dave Jiang
2024-06-03 15:53 ` [PATCH 4/8] taint: Add TAINT_FWCTL Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 5/8] fwctl: FWCTL_RPC to execute a Remote Procedure Call to device firmware Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 6/8] fwctl: Add documentation Jason Gunthorpe
2024-06-05 2:31 ` Randy Dunlap
2024-06-05 16:03 ` Jason Gunthorpe
2024-06-05 20:14 ` Randy Dunlap
2024-06-03 15:53 ` [PATCH 7/8] fwctl/mlx5: Support for communicating with mlx5 fw Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 8/8] mlx5: Create an auxiliary device for fwctl_mlx5 Jason Gunthorpe
2024-06-03 18:42 ` [PATCH 0/8] Introduce fwctl subystem Jakub Kicinski
2024-06-04 3:01 ` David Ahern
2024-06-04 14:04 ` Jakub Kicinski
2024-06-04 21:28 ` Saeed Mahameed
2024-06-04 22:32 ` Jakub Kicinski
2024-06-05 14:50 ` Jason Gunthorpe
2024-06-05 15:41 ` Jakub Kicinski
2024-06-04 23:56 ` Dan Williams
2024-06-05 3:05 ` Jakub Kicinski
2024-06-05 11:19 ` Jonathan Cameron
2024-06-05 13:59 ` Jason Gunthorpe
2024-06-06 2:35 ` David Ahern
2024-06-06 14:18 ` Jakub Kicinski
2024-06-06 14:48 ` Jason Gunthorpe
2024-06-06 15:05 ` Jakub Kicinski
2024-06-06 17:47 ` David Ahern
2024-06-07 6:48 ` Jiri Pirko
2024-06-07 14:50 ` David Ahern
2024-06-07 15:14 ` Jason Gunthorpe
2024-06-07 15:50 ` Jiri Pirko
2024-06-07 17:24 ` Jason Gunthorpe
2024-06-07 7:34 ` Jiri Pirko
2024-06-07 12:49 ` Andrew Lunn
2024-06-07 13:34 ` Jiri Pirko
2024-06-08 1:43 ` Jakub Kicinski
2024-06-06 4:56 ` Dan Williams
2024-06-06 8:50 ` Leon Romanovsky
2024-06-06 22:11 ` Dan Williams
2024-06-07 0:02 ` Jason Gunthorpe
2024-06-07 13:12 ` Leon Romanovsky
2024-06-06 14:41 ` Jason Gunthorpe
2024-06-06 14:58 ` Jakub Kicinski
2024-06-06 17:24 ` Dan Williams
2024-06-07 0:25 ` Jason Gunthorpe
2024-06-07 10:47 ` Przemek Kitszel
2024-06-11 15:36 ` Daniel Vetter
2024-06-11 16:17 ` Jason Gunthorpe
2024-06-11 16:54 ` Daniel Vetter
2024-06-06 1:58 ` David Ahern
2024-06-05 3:11 ` Jakub Kicinski
2024-06-05 12:06 ` 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=20240604180555.000063c2@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=aron.silverton@oracle.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dsahern@kernel.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=leon@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=patches@lists.linux.dev \
--cc=saeedm@nvidia.com \
--cc=tariqt@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).