Re: [PATCH] leds: trigger: Disable CPU trigger on PREEMPT_RT

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2021-09-27 at 17:18 +0000, Sebastian Andrzej Siewior wrote:
> On 2021-09-27 17:44:51 [+0200], Pavel Machek wrote:
> > 
> > Would you mind reading and responding to the rest of the email?
> 
> The patch you mentioned,
>   https://https://lkml.kernel.org/r/.kernel.org/all/20210915181601.99a68f5718be.I1a28b342d2d52cdeeeb81ecd6020c25cbf1dbfc0@changeid/
> 
> would remove the lock from led_trigger_event().
> Are there any guarantees how many callbacks maybe invoked and what kind
> of locks may be acquired?

In a way, the point of my patch is that after it we don't have to *care*
what locking happens in the callbacks.

The problem in our driver was that we did a spinlock without disabling
IRQs there in the callback, and that interacts badly with the rwlock in
the LED subsystem.

> Leaving kworker usage aside there are still things like spinlock_t usage
> in input_leds_brightness_set(), nic78bx_brightness_set() (from a quick
> grep) which have the same problems.

Looks like *everything* (that can work on ARM) and uses a spinlock would
have this problem? My patch doesn't address that at all. In fact, like I
said above, the entire point of the patch is to remove restrictions on
what the locking in the underlying LED driver can be.

johannes