[lkml]   [1998]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:43    [W:0.161 / U:5.912 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site