linux-kernel - Re: use of preempt_count instead of in

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20080321021020.GA28989@khazad-dum.debian.net>
Date:	Thu, 20 Mar 2008 23:10:20 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Richard Purdie <rpurdie@...ys.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	David Brownell <david-b@...bell.net>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c

On Fri, 21 Mar 2008, Richard Purdie wrote:
> The LED interface said that the brightness_set implementation should not
> sleep since it was intended to be a 'cheap' function and to allow LED
> triggers changing the LED brightness to be simple. A lot of embedded LED
> hardware doesn't need to sleep to toggle gpios.

So far so good.

> Some drivers do have a problem with that however and its usually been
> suggested they offload the brightness changes into a workqueue. The gpio

Also good.  But the fact is, the LED core *does* know when it is calling
from a scheduleable context (e.g. from sysfs handlers), and that's not an
uncommon path either.

The trigger code is more complicated, I don't know if most of its calls to
brightness_set are in safe or unsafe contexts for sleep.  But the people
calling the trigger code certainly would.

> * fix the gpio driver not to be so clever and clearly document
> * move the workqueue into the LED class, use it for everyone and remove
> the limitation of the function (punishes the hardware which doesn't need
> to sleep)
> * move the workqueue into the LED class and have LED drivers state
> whether they can sleep or not
> * start passing around GFP_* flags
> 
> Passing flags around and maintaining a track of schedulable state for
> the LED class sounds like overkill. I also don't like the idea of

It is the preferred way to do these things.  If you don't do it like that,
both gpio and *all* ACPI-based LED devices will have to always defer to
workqueues.

> So I'm leaning towards 'fixing' the gpio driver as I think David has
> already offered. I will also improve the documentation on this function
> and its requirements as I agree the current isn't as clear as it should
> be.

And we will have to always defer to workqueues on drivers that can't operate
from an atomic/interrupt context?  Even when there would be no need for it
because brightness_set is not being called from an non-scheduleable context
at all?

I hope I can live with that for LEDs (I have to think about LED
brightness_get first before I am sure about that), but I don't like it at
all for the long term.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/