All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Cc: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>,
	linux-coco@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Jeremy Linton <jeremy.linton@arm.com>,
	Jonathan Cameron <jic23@kernel.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Will Deacon <will@kernel.org>,
	Steven Price <steven.price@arm.com>,
	Suzuki K Poulose <Suzuki.Poulose@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Sudeep Holla <sudeep.holla@kernel.org>
Subject: Re: [PATCH v11 1/7] firmware: smccc: Add an Arm SMCCC bus
Date: Mon, 14 Sep 2026 19:28:36 -0300	[thread overview]
Message-ID: <20260914222836.GO3968357@nvidia.com> (raw)
In-Reply-To: <20260914133249.00007d35@oss.qualcomm.com>

On Mon, Sep 14, 2026 at 01:32:49PM -0700, Jonathan Cameron wrote:
> > +struct arm_smccc_device *arm_smccc_device_register(const char *name, u32 func_id)
> > +{
> > +	int ret;
> > +	struct arm_smccc_device *smccc_dev;
> > +
> > +	if (!name)
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	smccc_dev = kzalloc_obj(*smccc_dev);
> > +	if (!smccc_dev)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	smccc_dev->func_id = func_id;
> > +	smccc_dev->dev.bus = &arm_smccc_bus_type;
> > +	smccc_dev->dev.release = arm_smccc_release_device;
> > +
> > +	ret = dev_set_name(&smccc_dev->dev, "%s", name);
> 
> Does protecting the string defeat the nice underlying const handling?
> e.g.
> 	ret = dev_set_name(&smccc_dev->dev, name);
> might be better.

Pedenatically the %s is better as it doesn't restrict name to not
include % characters. 

> you'd often see this between an device_initialize() and device_add()
> and then we'd be relying on the device_put() to clean it up.
> 
> So as this stands this is fragile as any error paths that later
> get added...

Yes, but as written it is OK, and this is a common pattern in the
kernel. I agree it is fragile tricky..

Still it isn't an urgent reason to change it around, but the best
pattern is to put the allocate, dev.release=, and device_initialize()
in one 'alloc' function. Then the other function calls it and always
unwinds with put_device. Use device_add().

This avoids mixing the different kfree/put_device error unwind regimes
into the same function..

> > +	if (ret) {
> > +		kfree(smccc_dev);
> > +		return ERR_PTR(ret);
> > +	}
> > +
> 
> here can't free the name allocation.

The funky reasoning is since name failed there is no name allocation
to free

And then device_register() failure must always be done with
put_device, so it will capture the name. As long as name/register are
a pair with nothing between it is "fine".

Jason


  reply	other threads:[~2026-09-14 22:29 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14  6:05 [PATCH v11 0/7] Switch Arm SMCCC firmware services to an SMCCC bus Aneesh Kumar K.V (Arm)
2026-09-14  6:05 ` [PATCH v11 1/7] firmware: smccc: Add an Arm " Aneesh Kumar K.V (Arm)
2026-09-14 13:03   ` Catalin Marinas
2026-09-14 20:32   ` Jonathan Cameron
2026-09-14 22:28     ` Jason Gunthorpe [this message]
2026-09-15  9:22       ` Aneesh Kumar K.V
2026-09-15 11:46         ` Jason Gunthorpe
2026-09-23 16:43           ` Jonathan Cameron
2026-09-14  6:05 ` [PATCH v11 2/7] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device Aneesh Kumar K.V (Arm)
2026-09-14 13:14   ` Catalin Marinas
2026-09-14 20:39   ` Jonathan Cameron
2026-09-24 12:23   ` Sudeep Holla
2026-09-14  6:05 ` [PATCH v11 3/7] firmware: arm_rmm: Move RSI support out of arch/arm64 Aneesh Kumar K.V (Arm)
2026-09-14 13:18   ` Catalin Marinas
2026-09-14 20:45   ` Jonathan Cameron
2026-09-16 10:58   ` Catalin Marinas
2026-09-14  6:05 ` [PATCH v11 4/7] arm64: realm: Move Realm memory encryption ops to RSI code Aneesh Kumar K.V (Arm)
2026-09-14 13:20   ` Catalin Marinas
2026-09-14 14:50     ` Suzuki K Poulose
2026-09-16 15:21   ` Suzuki K Poulose
2026-09-14  6:05 ` [PATCH v11 5/7] virt: coco: arm-cca-guest: Rename TSM report source file Aneesh Kumar K.V (Arm)
2026-09-14 13:23   ` Catalin Marinas
2026-09-14 15:06   ` Suzuki K Poulose
2026-09-14 20:48   ` Jonathan Cameron
2026-09-14  6:05 ` [PATCH v11 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device Aneesh Kumar K.V (Arm)
2026-09-14 13:42   ` Catalin Marinas
2026-09-14 20:51   ` Jonathan Cameron
2026-09-16 12:46   ` Jason Gunthorpe
2026-09-24 12:24   ` Sudeep Holla
2026-09-14  6:05 ` [PATCH v11 7/7] coco: guest: arm64: Replace dummy CCA device with sysfs ABI Aneesh Kumar K.V (Arm)
2026-09-14 13:48   ` Catalin Marinas
2026-09-14 21:00   ` Jonathan Cameron
2026-09-16 10:57   ` Catalin Marinas
2026-09-16 14:09     ` Aneesh Kumar K.V
2026-09-17  9:56       ` Catalin Marinas

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=20260914222836.GO3968357@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=Suzuki.Poulose@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeremy.linton@arm.com \
    --cc=jic23@kernel.org \
    --cc=jonathan.cameron@oss.qualcomm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=steven.price@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=sudeep.holla@kernel.org \
    --cc=will@kernel.org \
    /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.