mirror of
https://github.com/torvalds/linux.git
synced 2026-10-07 05:31:08 -04:00
The ACPI_PREEMPTION_POINT() logic was introduced in commit8bd108d(ACPICA: add preemption point after each opcode parse). The follow up commitsabe1dfab6,138d15692,c084ca70tried 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 [[email protected]: fix build] Signed-off-by: Thomas Gleixner <[email protected]> Cc: Len Brown <[email protected]> Cc: Francois Valenduc <[email protected]> Cc: Lin Ming <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>