Messages in this thread | | | Date | Sat, 11 Jul 1998 21:40:21 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Strange interrupt behaviour |
| |
On Sat, 11 Jul 1998, Richard B. Johnson wrote: > > No. That just masks the problem. It is common for Linux interrupt handlers > to enable interrupts. They must _not_ be reentered. The kernel IRQ code > should:
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
| |