Messages in this thread | | | Date | Thu, 08 Mar 2007 09:43:47 +0200 | From | Avi Kivity <> | Subject | Re: Wanted: simple, safe x86 stack overflow detection |
| |
Bill Irwin wrote: > On Tue, 2007-03-06 at 22:44 -0800, Bill Irwin wrote: > >>> What do you see as the obstacle to eliminating nested IRQ's? >>> > > On Wed, Mar 07, 2007 at 04:34:52AM -0800, Arjan van de Ven wrote: > >> political will, or maybe just the lack of convincing people so far >> > > Political issues are significantly more difficult to resolve than > technical ones. > > > On Tue, 2007-03-06 at 22:44 -0800, Bill Irwin wrote: > >>> It doesn't >>> seem so far out to test for being on the interrupt stack and defer the >>> call to do_IRQ() until after the currently-running instance of do_IRQ() >>> has returned, or to move to per-irq stacks modulo special arrangements >>> for the per-cpu IRQ's. Or did you have other methods in mind? >>> > > On Wed, Mar 07, 2007 at 04:34:52AM -0800, Arjan van de Ven wrote: > >> it's simpler... >> irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action) >> { >> irqreturn_t ret, retval = IRQ_NONE; >> unsigned int status = 0; >> >> handle_dynamic_tick(action); >> >> if (!(action->flags & IRQF_DISABLED)) >> local_irq_enable_in_hardirq(); >> >> just removing the if() and the explicit IRQ enabling already makes irqs no longer nest... >> > > I can see why that would raise eyebrows. I can see getting bashed > mercilessly with interrupt latency concerns as a result here. Can you > suggest any defenses? >
I don't understand why interrupt latency suffers. Sure, the interrupt that's being masked is delayed, but on the other hand the interrupt that's doing the masking is not. We're moving the latency from the first interrupt to the second, probably with a slight gain in overall throughput.
It *does* matter if the interrupts have meaningful priorities. Is that the case here?
-- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |