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: <20080320225612.GB20788@khazad-dum.debian.net>
Date:	Thu, 20 Mar 2008 19:56:12 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	David Brownell <david-b@...bell.net>,
	Richard Purdie <rpurdie@...ys.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 Tue, 18 Mar 2008, Andrew Morton wrote:
> On Sun, 16 Mar 2008 11:46:23 -0800 David Brownell <david-b@...bell.net> wrote:
> > On Sunday 16 March 2008, Henrique de Moraes Holschuh wrote:
> > > Is the use of "if (preempt_count())" to know when to defer led gpio work to
> > > a workqueue needed? __Shouldn't "if (in_atomic())" be enough?
> > 
> > At this point, I don't know of any such reason.
> > 
> > I remember hunting for the right heuristic, and settling on
> > that one for reasons that I can't recall now.  They may even
> > be no longer applicable.
> 
> Both are incorrect.  When CONFIG_PREEMPT=n we have no support for
> determining whether schedule() may be called.  The calling code has to sort
> out its stuff on its own.
> 
> <greps for preempt_count>
> 
> The LEDs code seems to be the sole offender.  print_vma_addr() might be
> wrong too, but Ingo did it, and perhaps he knows that all code paths which
> call print_vma_addr() from deadlockable contexts have already called
> inc_preempt_count().  But is that true for all architectures?
> 
> <greps for in_atomic>
> 
> omigawd, what have we done, and how can we fix it? :(

Well, it is obvious an "are we in a sleep-ok state?" query that works in any
case is desired by a lot of code.

I certainly don't want to punt every thinkpad LED write to a workqueue,
because that would mean less time with the CPU in C3 in the bottom line,
even if there are some benefits to always doing it the workqueue way (the
workqueue helper colapses attempts to change the LED state too often).

Can we add "in_scheduleable()", or maybe "can_schedule()", that returns
in_atomic() if CONFIG_PREEMT, or 0 if there is no way to know?   To my
limited knowledge of how that part of the kernel works, it would do the
right thing.

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