summaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/modules.py
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2025-07-31 16:12:19 +0200
committerBorislav Petkov (AMD) <bp@alien8.de>2025-08-25 11:05:27 +0200
commit1b558e14f3c17dc29ce2e8cd0b8bd385e108734b (patch)
treee17cd85dfd8382e5e2db6b54966ef5921877eb83 /scripts/gdb/linux/modules.py
parent1b237f190eb3d36f52dffe07a40b5eb210280e00 (diff)
x86/apic: Make the ISR clearing sane
apic_pending_intr_clear() is fundamentally voodoo programming. It's primary purpose is to clear stale ISR bits in the local APIC, which would otherwise lock the corresponding interrupt priority level. The comments and the implementation claim falsely that after clearing the stale ISR bits, eventually stale IRR bits would be turned into ISR bits and can be cleared as well. That's just wishful thinking because: 1) If interrupts are disabled, the APIC does not propagate an IRR bit to the ISR. 2) If interrupts are enabled, then the APIC propagates the IRR bit to the ISR and raises the interrupt in the CPU, which means that code _cannot_ observe the ISR bit for any of those IRR bits. Rename the function to reflect the purpose and make exactly _one_ attempt to EOI the pending ISR bits and add comments why traversing the pending bit map in low to high priority order is correct. Instead of trying to "clear" IRR bits, simply print a warning message when the IRR is not empty. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/871ppwih4s.ffs@tglx
Diffstat (limited to 'scripts/gdb/linux/modules.py')
0 files changed, 0 insertions, 0 deletions