drivers/parisc/led.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
When platform_device_register() fails in startup_leds(), the embedded
struct device in platform_leds has already been initialized by
device_initialize(), but the failure path only reports the error and
does not drop the device reference for the current platform device:
startup_leds()
-> platform_device_register(&platform_leds)
-> device_initialize(&platform_leds.dev)
-> setup_pdev_dma_masks(&platform_leds)
-> platform_device_add(&platform_leds)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() after reporting the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: 789e527adfc33 ("parisc: led: Rewrite LED/LCD driver to utilizize Linux LED subsystem")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/parisc/led.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/parisc/led.c b/drivers/parisc/led.c
index 016c9d5a60a8..b299fcc48b08 100644
--- a/drivers/parisc/led.c
+++ b/drivers/parisc/led.c
@@ -543,8 +543,10 @@ static void __init register_led_regions(void)
static int __init startup_leds(void)
{
- if (platform_device_register(&platform_leds))
- printk(KERN_INFO "LED: failed to register LEDs\n");
+ if (platform_device_register(&platform_leds)) {
+ pr_info("LED: failed to register LEDs\n");
+ platform_device_put(&platform_leds);
+ }
register_led_regions();
return 0;
}
--
2.43.0
On 4/15/26 19:05, Guangshuo Li wrote:
> When platform_device_register() fails in startup_leds(), the embedded
> struct device in platform_leds has already been initialized by
> device_initialize(), but the failure path only reports the error and
> does not drop the device reference for the current platform device:
>
> startup_leds()
> -> platform_device_register(&platform_leds)
> -> device_initialize(&platform_leds.dev)
> -> setup_pdev_dma_masks(&platform_leds)
> -> platform_device_add(&platform_leds)
>
> This leads to a reference leak when platform_device_register() fails.
> Fix this by calling platform_device_put() after reporting the error.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Fixes: 789e527adfc33 ("parisc: led: Rewrite LED/LCD driver to utilizize Linux LED subsystem")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/parisc/led.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
applied.
Thanks!
Helge
On 17. 04. 26, 11:39, Helge Deller wrote:
> On 4/15/26 19:05, Guangshuo Li wrote:
>> When platform_device_register() fails in startup_leds(), the embedded
>> struct device in platform_leds has already been initialized by
>> device_initialize(), but the failure path only reports the error and
>> does not drop the device reference for the current platform device:
>>
>> startup_leds()
>> -> platform_device_register(&platform_leds)
>> -> device_initialize(&platform_leds.dev)
>> -> setup_pdev_dma_masks(&platform_leds)
>> -> platform_device_add(&platform_leds)
>>
>> This leads to a reference leak when platform_device_register() fails.
>> Fix this by calling platform_device_put() after reporting the error.
>>
>> The issue was identified by a static analysis tool I developed and
>> confirmed by manual review.
>>
>> Fixes: 789e527adfc33 ("parisc: led: Rewrite LED/LCD driver to
>> utilizize Linux LED subsystem")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
>> ---
>> drivers/parisc/led.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> applied.
> Thanks!
> Helge
Unless the static pcmtst_pdev has ->type->release or ->release set, the
patch triggers a warning upon put().
platform_device_register() should be fixed instead.
See also:
https://patchew.org/linux/20260415174159.3625777-1-lgs201920130244@gmail.com/
thanks,
--
js
suse labs
Hi Jiri,
On 4/23/26 07:24, Jiri Slaby wrote:
> On 17. 04. 26, 11:39, Helge Deller wrote:
>> On 4/15/26 19:05, Guangshuo Li wrote:
>>> When platform_device_register() fails in startup_leds(), the embedded
>>> struct device in platform_leds has already been initialized by
>>> device_initialize(), but the failure path only reports the error and
>>> does not drop the device reference for the current platform device:
>>>
>>> startup_leds()
>>> -> platform_device_register(&platform_leds)
>>> -> device_initialize(&platform_leds.dev)
>>> -> setup_pdev_dma_masks(&platform_leds)
>>> -> platform_device_add(&platform_leds)
>>>
>>> This leads to a reference leak when platform_device_register() fails.
>>> Fix this by calling platform_device_put() after reporting the error.
>>>
>>> The issue was identified by a static analysis tool I developed and
>>> confirmed by manual review.
>>>
>>> Fixes: 789e527adfc33 ("parisc: led: Rewrite LED/LCD driver to utilizize Linux LED subsystem")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
>>> ---
>>> drivers/parisc/led.c | 6 ++++--
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> applied.
>> Thanks!
>> Helge
>
> Unless the static pcmtst_pdev has ->type->release or ->release set, the patch triggers a warning upon put().
>
> platform_device_register() should be fixed instead.
Thanks for the notice! I'm going to revert that patch.
Just yesterday I refused to apply the other patches for fbdev and suggested
to fix platform_device_register() instead. See:
https://marc.info/?l=linux-fbdev&m=177687117206684&w=2
> See also:
> https://patchew.org/linux/20260415174159.3625777-1-lgs201920130244@gmail.com/
Thanks!
Helge
Hi Jiri, Helge,
Thanks for pointing this out, and thanks Helge for taking care of the
revert.
On Thu, 23 Apr 2026 at 15:09, Helge Deller <deller@gmx.de> wrote:
>
> Hi Jiri,
>
> On 4/23/26 07:24, Jiri Slaby wrote:
> > On 17. 04. 26, 11:39, Helge Deller wrote:
> >> On 4/15/26 19:05, Guangshuo Li wrote:
> >>> When platform_device_register() fails in startup_leds(), the embedded
> >>> struct device in platform_leds has already been initialized by
> >>> device_initialize(), but the failure path only reports the error and
> >>> does not drop the device reference for the current platform device:
> >>>
> >>> startup_leds()
> >>> -> platform_device_register(&platform_leds)
> >>> -> device_initialize(&platform_leds.dev)
> >>> -> setup_pdev_dma_masks(&platform_leds)
> >>> -> platform_device_add(&platform_leds)
> >>>
> >>> This leads to a reference leak when platform_device_register() fails.
> >>> Fix this by calling platform_device_put() after reporting the error.
> >>>
> >>> The issue was identified by a static analysis tool I developed and
> >>> confirmed by manual review.
> >>>
> >>> Fixes: 789e527adfc33 ("parisc: led: Rewrite LED/LCD driver to utilizize Linux LED subsystem")
> >>> Cc: stable@vger.kernel.org
> >>> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> >>> ---
> >>> drivers/parisc/led.c | 6 ++++--
> >>> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> applied.
> >> Thanks!
> >> Helge
> >
> > Unless the static pcmtst_pdev has ->type->release or ->release set, the patch triggers a warning upon put().
> >
> > platform_device_register() should be fixed instead.
>
> Thanks for the notice! I'm going to revert that patch.
>
> Just yesterday I refused to apply the other patches for fbdev and suggested
> to fix platform_device_register() instead. See:
> https://marc.info/?l=linux-fbdev&m=177687117206684&w=2
>
> > See also:
> > https://patchew.org/linux/20260415174159.3625777-1-lgs201920130244@gmail.com/
> Thanks!
> Helge
I agree that this patch is not appropriate. platform_leds is a static
platform_device and it does not provide a dev.release callback, so calling
platform_device_put() on the platform_device_register() failure path can
trigger the missing release callback warning.
Please disregard this patch. I will drop it, and I am also going through
the other patches I sent for the same pattern and following up where they
should be ignored or reverted.
Sorry for the noise.
Best regards,
Guangshuo Li
© 2016 - 2026 Red Hat, Inc.