lkml.org 
[lkml]   [2007]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2007-03-08 08:51    [W:0.507 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site