On Tue, 20 Jul 2010 15:16:51 -0700 akpm@xxxxxxxxxxxxxxxxxxxx wrote: > From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > 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. -- 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
