diff options
| author | Thomas Gleixner <tglx@linutronix.de> | 2025-07-31 16:12:19 +0200 |
|---|---|---|
| committer | Borislav Petkov (AMD) <bp@alien8.de> | 2025-08-25 11:05:27 +0200 |
| commit | 1b558e14f3c17dc29ce2e8cd0b8bd385e108734b (patch) | |
| tree | e17cd85dfd8382e5e2db6b54966ef5921877eb83 /scripts/gdb/linux/modules.py | |
| parent | 1b237f190eb3d36f52dffe07a40b5eb210280e00 (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
