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]

Date:	Wed, 26 Mar 2008 13:17:24 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	David Brownell <david-b@...bell.net>, rpurdie@...ys.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, 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
> > 
> > Just a "leaning..." comment:
> > 
> > 	http://marc.info/?l=linux-kernel&m=120606104619198&w=2
> > 
> > Seems to me that by now there ought to be resolution on at least
> > one of the issues brought up on this thread.  :)
> 
> Is it reasonable to have two version of that subroutine: one meant to 
> be called in a sleepable context and the other to be called when 
> sleeping isn't allowed?

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.

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