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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 26 Mar 2008 16:46:09 +0000
From:	Richard Purdie <rpurdie@...ys.net>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	David Brownell <david-b@...bell.net>, gitster@...ox.com,
	corbet@....net, mingo@...e.hu, mb@...sch.de,
	linux-kernel@...r.kernel.org, khali@...ux-fr.org,
	geert@...ux-m68k.org, akpm@...ux-foundation.org
Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c


On Wed, 2008-03-26 at 13:17 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 26 Mar 2008, Alan Stern wrote:
> > On Tue, 25 Mar 2008, David Brownell wrote:
> > > I _almost_ hate bringing this lovely flamage back onto $SUBJECT ... but
> > > what's the resolution for the leds-gpio.c issue?  I've not seen a merge
> > > notice for the patch I submitted a week ago now:
> > > 
> > > 	http://marc.info/?l=linux-kernel&m=120597839009399&w=2
>
[...]
> I have changed the thinkpad-acpi leds code to always assume an atomic
> context, but I too would appreciate a proper flag (or secondary hook)
> from the LED class to know when I am in an atomic context or not.
> 
> LED Triggers also need to be modified, they are mostly called from an
> atomic context so we have to assume that by default, but we'd do well to
> add a way to call them from non-atomic contexts.
> 
> Richard?  AFAIK, the ball *is* in your court as the LED maintainer.  You
> have to decide which way to go and tell us.  I suppose either I or Alan
> could write up patches to implement it, but I have better things to do
> than to write patches that would be rejected anyway... OTOH, I don't
> mind writing ones that I know are at least attempting to implement an
> approved idea and would be rejected only if they need some fixing.

I've been meaning to merge David's patch and will get that done shortly,
sorry for the delay.

As I've said, I don't really think we need context flags for the LED
class at the moment. As you say, most of the triggers are atomic context
and those which can sleep are not time critical so I don't really see
the point in the added complexity.

Cheers,

Richard


--
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/