Re: Wanted: simple, safe x86 stack overflow detection

[Avi Kivity <avi@argo.co.il>]

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.