lkml.org 
[lkml]   [2008]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: acpi_evaluate_integer broken by design
Hi!

> > Subject: acpi_evaluate_integer broken by design
>
> Please don't give patches daft and not very meaningful titles. It just
> means that someone else has to invent a useful title and then we get
> the same patch floating about with two different titles.

Sorry. I was kind of angry at that code because it does not contain
any remarks when it is okay to call it, etc.

> > Date: Tue, 25 Nov 2008 12:05:08 +0100
> > Sender: linux-kernel-owner@vger.kernel.org
> > User-Agent: Mutt/1.5.18 (2008-05-17)
> >
> >
> > Now I know why I had strange "scheduling in atomic" problems:
> > acpi_evaluate_integer() does malloc(..., irqs_disabled() ? GFP_ATOMIC
> > : GFP_KERNEL)... which is (of course) broken.
>
> That is kinda weird. When did this all start happening?

With the HP LED driver... so this is "would be nice for 2.6.28, not
worth backporting" material.

> > There's no way to reliably tell if we need GFP_ATOMIC or not from
> > code, this one for example fails to detect spinlocks held.
> >
> > Fortunately, allocation seems small enough to be done on stack.
>
> It's 24 bytes in an x86_64 allmodconfig build. Clearly it should be a
> local.

Yep.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


\
 
 \ /
  Last update: 2008-11-27 14:59    [W:0.068 / U:0.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site