Note that the kernel IRQ code _does_ this. It's harder to do with the
IO-APIC, but it's actually done fairly cleanly and straightforwardly, and
there is a very simple atomic flag that makes sure of that even if the
hardware tries to get recursive interrupts through (which can actually
happen reasonably easily on systems that send interrupts to multiple
CPU's, and where the kernel needs to make sure that only one of them is
accepted).
In addition to the software lock, the kernel also disables the interrupt
on the interrupt controller, but the software lock is still required
partly because the interrupt controller is not actually synchronized to
the CPU any more (a 8259 is synchronous, but a IO-APIC is not - the
IO-APIC uses a fairly complicated bus protocol which essentially allows an
interrupt to reach the CPU after the CPU has told it to shut up - thus the
need for software locks too)
Note that the CPU locking is so simple that I really don't think you get
nested interrupts. Look at "desc->status" and the "IRQ_INPROGRESS" etc
handling in io_apic.c (which is all protected by the "irq_controller_lock"
spinlock to make sure that everything is completely serialized even on
multiple CPU's).
This is why I suspect there is something else going on. Bottom half
handling is not at all as straightforward, for example, and if somebody
wanted to look for holes, I'd suggest looking there first (feel free to
look at io_apic.c too - I'd be more than happy to have bugs found, I just
suspect it isn't the first place to check).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html