Re: [PATCH v6 09/12] leds: trigger: Add led_trigger_notify_hw_control_changed() interface

[Rong Zhang <i@rong.moe>]

Hi Lee,

On Wed, 2026-09-02 at 18:15 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Uninitialized work_struct leads to NULL pointer dereference

I believe this is an LLM hallucination. See below.

> --
> 
> commit b9b9203cb3b45eb3bbf3490673a89b53a7df12ae
> Author: Rong Zhang <i@rong.moe>
> 
> leds: trigger: Add led_trigger_notify_hw_control_changed() interface
> 
> This commit introduces a new interface to notify the LED core about
> hardware-initiated trigger transitions. It adds a workqueue deferral
> mechanism to safely handle these transitions.
> 
> > diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> > index 7e571bd1de5b3..3b438d8da5e0c 100644
> > --- a/drivers/leds/led-class.c
> > +++ b/drivers/leds/led-class.c
> 
> [ ... ]
> 
> > @@ -611,6 +611,9 @@ int led_classdev_register_ext(struct device *parent,
> >  	led_trigger_set_default(led_cdev);
> >  #endif
> >  
> > +	if (led_cdev->flags & LED_TRIG_HW_CHANGED)
> > +		led_trigger_init_hw_changed(led_cdev);
> > +
> 
> [Severity: High]
> Is it safe to initialize the work_struct after activating the default
> trigger?
> 
> By the time led_trigger_init_hw_changed() is called,
> led_trigger_set_default() has already run and the device is active. If a
> hardware interrupt or userspace action fires in this small window, it could
> invoke the notification before the work_struct is fully initialized.
> 
> >  	mutex_unlock(&led_cdev->led_access);
> 
> [ ... ]
> 
> > diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
> > index cb49a02a8b3cf..a9d992a886161 100644
> > --- a/drivers/leds/led-triggers.c
> > +++ b/drivers/leds/led-triggers.c
> 
> [ ... ]
> 
> > +void led_trigger_notify_hw_control_changed(struct led_classdev *led_cdev, bool activate)
> > +{
> > +	/* Restricted to private triggers. */
> > +	if (WARN_ON(!(led_cdev->flags & LED_TRIG_HW_CHANGED) ||
> > +		    !led_cdev->hw_control_trigger || !led_cdev->trigger_type))
> > +		return;
> > +
> > +	WRITE_ONCE(led_cdev->triggers_hw_changed, activate);
> > +
> > +	schedule_work(&led_cdev->triggers_hw_changed_work);
> 
> [Severity: High]
> If this notification is triggered during the registration window mentioned
> above, will this schedule an uninitialized work_struct?

The LED driver apparently cannot call anything on the LED device during
the registration. If the driver lost its sanity and did so, it would
break tons of things, not limited to the "concern" here.

Therefore, this is not a valid concern and should be considered as an LLM
hallucination.

Thanks,
Rong

> 
> Scheduling a zero-initialized work_struct means the function pointer is NULL,
> which will cause a kernel panic when the worker thread attempts to execute it.
> 
> > +}