[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081127135651.GA6104@atrey.karlin.mff.cuni.cz>
Date: Thu, 27 Nov 2008 14:56:51 +0100
From: Pavel Machek <pavel@...e.cz>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
len.brown@...el.com
Subject: Re: 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@...r.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
--
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/
Powered by blists - more mailing lists