linux-kernel - Re: [PATCH] leds: use led_brightness_set in led_trigger

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1339450705.23857.16.camel@lorien2>
Date:	Mon, 11 Jun 2012 15:38:25 -0600
From:	Shuah Khan <shuahkhan@...il.com>
To:	Fabio Baltieri <fabio.baltieri@...il.com>
Cc:	shuahkhan@...il.com, Bryan Wu <bryan.wu@...onical.com>,
	linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org,
	Richard Purdie <rpurdie@...ys.net>
Subject: Re: [PATCH] leds: use led_brightness_set in led_trigger_event

On Mon, 2012-06-11 at 22:57 +0200, Fabio Baltieri wrote:
> Fix led_trigger_event() to use led_brightness_set() instead of
> led_set_brightness(), so that any pending blink timer is stopped before
> setting the new brightness value.  Without this fix LED status may be
> overridden by a pending timer.
> 
> This allows a trigger to use a mix of led_trigger_event(),
> led_trigger_blink() and led_trigger_blink_oneshot() without races.
> 
> Signed-off-by: Fabio Baltieri <fabio.baltieri@...il.com>
> Cc: Bryan Wu <bryan.wu@...onical.com>
> ---
> Hi Bryan,
> 
> I found this one while working on another patch but I think it's also needed by
> other drivers which mixes led_trigger_blink() and led_trigger_event(), such as
> power_supply_leds.
> 
> Without this a led don't stop blinking as it should when calling
> led_trigger_event().

Good find. This is very subtle race though because both timer and
oneshot triggers call led_brightness_set() from their deactivate
routines. Is this when these events triggered using oneshot trigger? 

> 
> Should not cause any harm on other drivers.
> 
> (I'm starting to find the whole led_set_brightness/led_brightness_set thing a
> bit confusing BTW...)

I agree with the names are confusing. :) It found it confusing as well.
Probably why we have this bug hiding until led_trigger_blink() came
along.

led_brightness_set() calls led_set_brightness(). led_set_brightness()
takes cares about whether the driver is in suspend state and invokes
driver's brightness_set interface. Maybe led_clear_blink_timer() would
be a better name for this led_brightness_set() routine.

I can volunteer to make this change if we agree that this will be a good
one to clear this naming confusion.

-- Shuah

> 
> Fabio
> 
>  drivers/leds/led-triggers.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
> index fa0b9be..b88d3b9 100644
> --- a/drivers/leds/led-triggers.c
> +++ b/drivers/leds/led-triggers.c
> @@ -224,7 +224,7 @@ void led_trigger_event(struct led_trigger *trig,
>  		struct led_classdev *led_cdev;
>  
>  		led_cdev = list_entry(entry, struct led_classdev, trig_list);
> -		led_set_brightness(led_cdev, brightness);
> +		led_brightness_set(led_cdev, brightness);

This is in-line with led_trigger_set() which is calling
led_bightness_set() correctly. Also led_classdev_unregister() calls it I
think for the same reason so the blink timer can be stopped.

>  	}
>  	read_unlock(&trig->leddev_list_lock);
>  }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/