> On 11 Jul 1998, Andi Kleen wrote:
>
> > alan@lxorguk.ukuu.org.uk (Alan Cox) writes:
> >
> > > 3. Drivers that get repeated interrupts appear to re-enter the handler
> > > uncontrollably blow the stack and crash. I suspect nested interrupt
> > > handling problems may be half the 8K stack issue, and could be tons
> > > of our other remaining bugs.
> >
> > How about using a separate per-CPU 16K stack for interrupts, instead of
> > handling them on the per-process kernel stack? Then we could probably
> > switch back to 4K process kernel stacks too.
> >
>
> 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:
>
> Get IRQ N
> mask off IRQ N
> ack the interrupt (reset in-service flag)
> call interrupt handler
> interrupt handler returns
> unmask IRQ N
> Interrupt return
You are making too much assumptions on the actual effect of "mask off IRQ"
and "ACK the interrupt" or you are only addressing the edge triggered
interrupt scheme in when interrupts are handled by one processor.
PCI has defined an "Interrupt acknowledge" transaction, but it seems that
devices donnot implement it. So the only way to actually "ack the
interrupt" is to remove the cause of this interrupt and only the device
driver is able to do that.
If you want to mask an IRQ when you are using an IOAPIC, then you have to
mask it at IOAPIC level and this uses the APIC BUS and so this operation
cannot be atomic but is totaly asynchronous.
> The kernel code has to 'remember' the IRQ bit that caused the interrupt
> in the first place. If the interrupt was masked OFF, (got a spurious
> interrupt), it must not unmask the interrupt. The kernel handler can't
> just save/restore the whole mask because the mask might have changed
> by the time the driver code returns. It has to save/restore the bit
> from the original mask and leave the other, possibly-changed, ones
> alone.
You can try to do lots of clever things from the software, but if you
want to implement IRQ stuff using your scheme, you just have to pay for
having to deal with nested interrupt from the same IRQ source. Add to
this list the fact that the hardware is checking interrupt flags and may
return some "stated spurious" interrupts. BTW, you also are to be careful
not to lose interrupts which is possible with edge triggered interrupts.
Regards,
Gerard.
-
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