[PATCH 4/5] perf: arm: pmu: fix reference leak on failed device registration

[PATCH 4/5] perf: arm: pmu: fix reference leak on failed device registration

[Vastargazing]

When platform_device_register() fails in arm_acpi_register_pmu_device(),
the embedded struct device has already been initialized by
device_initialize() inside platform_device_register(). The error path
unregisters the GSI interrupt but returns without dropping the device
reference:

  arm_acpi_register_pmu_device()
    -> platform_device_register(pdev)
       -> device_initialize(&pdev->dev)   /* kref = 1 */
       -> platform_device_add(pdev)       /* fails */
    <- acpi_unregister_gsi() called, but kref still 1

Per platform_device_register() kernel-doc:

  NOTE: _Never_ directly free @pdev after calling this function, even if
  it returned an error! Always use platform_device_put() to give up the
  reference initialised in this function instead.

Fix this by calling platform_device_put() in the error branch before
unregistering the GSI.

Fixes: d24a0c7099b3 ("arm_pmu: acpi: spe: Add initial MADT/SPE probing")
Cc: stable@vger.kernel.org
Assisted-by: GitHub Copilot (Claude Sonnet 4.5)
Signed-off-by: Vastargazing <vebohr@gmail.com>
---
 drivers/perf/arm_pmu_acpi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
index e80f76d95e68..c2defbc32ad9 100644
--- a/drivers/perf/arm_pmu_acpi.c
+++ b/drivers/perf/arm_pmu_acpi.c
@@ -119,8 +119,10 @@ arm_acpi_register_pmu_device(struct platform_device *pdev, u8 len,
 
 	pdev->resource[0].start = irq;
 	ret = platform_device_register(pdev);
-	if (ret)
+	if (ret) {
+		platform_device_put(pdev);
 		acpi_unregister_gsi(gsi);
+	}
 
 	return ret;
 }
-- 
2.51.0

Re: [PATCH 4/5] perf: arm: pmu: fix reference leak on failed device registration

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Calling `platform_device_put()` on statically allocated platform devices triggers a kernel WARNING.
--

commit 3c982eab6d069fa3cf3109dda88a31b66ceb0afd
Author: Vastargazing <vebohr@gmail.com>

perf: arm: pmu: fix reference leak on failed device registration

When platform_device_register() fails in arm_acpi_register_pmu_device(),
this commit adds a call to platform_device_put() in the error branch to
prevent a reference leak.

> diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
> index e80f76d95e68..c2defbc32ad9 100644
> --- a/drivers/perf/arm_pmu_acpi.c
> +++ b/drivers/perf/arm_pmu_acpi.c
> @@ -119,8 +119,10 @@ arm_acpi_register_pmu_device(struct platform_device *pdev, u8 len,
>  
>  	pdev->resource[0].start = irq;
>  	ret = platform_device_register(pdev);
> -	if (ret)
> +	if (ret) {
> +		platform_device_put(pdev);

Because the devices passed to this function (spe_dev and trbe_dev) are
statically allocated and do not provide a .dev.release callback, will calling
platform_device_put() trigger a kernel warning?

When the reference count drops to 0, device_release() is invoked.
Since no release function is defined for these static objects, it triggers
the driver core warning about lacking a release() function, which could panic
the system if panic_on_warn is configured.

The kernel documentation's advice to use platform_device_put() applies
to dynamically allocated devices, not statically allocated global variables.

>  		acpi_unregister_gsi(gsi);
> +	}
>  
>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1777889235.git.vebohr@gmail.com?part=4

Re: [PATCH 4/5] perf: arm: pmu: fix reference leak on failed device registration

[Sudeep Holla]

On Mon, May 04, 2026 at 01:08:46PM +0300, Vastargazing wrote:
> When platform_device_register() fails in arm_acpi_register_pmu_device(),
> the embedded struct device has already been initialized by
> device_initialize() inside platform_device_register(). The error path
> unregisters the GSI interrupt but returns without dropping the device
> reference:
> 
>   arm_acpi_register_pmu_device()
>     -> platform_device_register(pdev)
>        -> device_initialize(&pdev->dev)   /* kref = 1 */
>        -> platform_device_add(pdev)       /* fails */
>     <- acpi_unregister_gsi() called, but kref still 1
> 
> Per platform_device_register() kernel-doc:
> 
>   NOTE: _Never_ directly free @pdev after calling this function, even if
>   it returned an error! Always use platform_device_put() to give up the
>   reference initialised in this function instead.
> 
> Fix this by calling platform_device_put() in the error branch before
> unregistering the GSI.
> 
> Fixes: d24a0c7099b3 ("arm_pmu: acpi: spe: Add initial MADT/SPE probing")
> Cc: stable@vger.kernel.org
> Assisted-by: GitHub Copilot (Claude Sonnet 4.5)
> Signed-off-by: Vastargazing <vebohr@gmail.com>
> ---
>  drivers/perf/arm_pmu_acpi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
> index e80f76d95e68..c2defbc32ad9 100644
> --- a/drivers/perf/arm_pmu_acpi.c
> +++ b/drivers/perf/arm_pmu_acpi.c
> @@ -119,8 +119,10 @@ arm_acpi_register_pmu_device(struct platform_device *pdev, u8 len,
>  
>  	pdev->resource[0].start = irq;
>  	ret = platform_device_register(pdev);
> -	if (ret)
> +	if (ret) {
> +		platform_device_put(pdev);

Both spe_dev and trbe_dev using this are statically allocated, what am I
missing here ? What will platform_device_put() do ?

-- 
Regards,
Sudeep

Re: [PATCH 1/5] perf/arm_pmu_acpi: fix reference leak in arm_pmu_acpi_probe error path

[Valery Borovsky]

Yeah, you're right, my bad. The `arm_pmu_acpi.c` patch is definitely broken.

Since `spe_dev` and `trbe_dev` are statically allocated, they don't have a
`.dev.release` callback. If we hit `platform_device_put()` here, the refcount
drops to zero and triggers `device_release()`, which is going to scream about
the missing release function. At best, we get a messy WARN; at worst, it'll
panic the kernel if someone's running with `panic_on_warn`.

The kernel-doc note about `platform_device_put()` is really meant for dynamic
allocations where the release path actually frees memory. For static setups
like this, the original code is actually the right way to go.

Please drop patches 1/5 through 4/5 from the v1 series—they all suffer from
the same logic error. Patch 5/5 (mfd: sm501) is the only clean one, so I've
re-sent that as a standalone v2.

Sorry for the noise.

Valery Borovsky