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@xxxxxxxxxxxxxxx > > 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
