Re: [patch for 2.6.35 1/1] acpi: fix bogus preemption logic

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 20 Jul 2010 15:16:51 -0700
akpm@linux-foundation.org wrote:

> From: Thomas Gleixner <tglx@linutronix.de>
> 
> The ACPI_PREEMPTION_POINT() logic was introduced in commit 8bd108d
> (ACPICA: add preemption point after each opcode parse).  The follow up
> commits abe1dfab6, 138d15692, c084ca70 tried to fix the preemption logic
> back and forth, but nobody noticed that the usage of
> in_atomic_preempt_off() in that context is wrong.
> 
> The check which guards the call of cond_resched() is:
> 
>     if (!in_atomic_preempt_off() && !irqs_disabled())
> 
> in_atomic_preempt_off() is not intended for general use as the comment
> above the macro definition clearly says:
> 
>  * Check whether we were atomic before we did preempt_disable():
>  * (used by the scheduler, *after* releasing the kernel lock)
> 
> On a CONFIG_PREEMPT=n kernel the usage of in_atomic_preempt_off() works by
> accident, but with CONFIG_PREEMPT=y it's just broken.
> 
> The whole purpose of the ACPI_PREEMPTION_POINT() is to reduce the latency
> on a CONFIG_PREEMPT=n kernel, so make ACPI_PREEMPTION_POINT() depend on
> CONFIG_PREEMPT=n and remove the in_atomic_preempt_off() check.
> 
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16210
> 

Why was this simply ignored?

I shall now add a cc:stable to my copy of the patch.  Please don't
merge the old version which is missing that cc.