Re: [PATCH] i386: Execute stack overflow warning on interrupt stackII

From: Andi Kleen
Date: Mon May 05 2008 - 06:21:15 EST


Thomas Gleixner wrote:
> On Fri, 2 May 2008, Andi Kleen wrote:
>> +static void stack_overflow(void)
>> +{
>> + printk("low stack detected by irq handler\n");
>
> Needs a KERN_ERR

Just moving code. If there is one added it should be in another patch.
Besides if anything it's a KERN_WARN I guess.

>
>> + /* Execute warning on interrupt stack */
>> + if (unlikely(overflow))
>> + call_on_stack2(stack_overflow, isp, 0, 0);
>> +
>> + call_on_stack2(desc->handle_irq, isp, irq, desc);
>
> arch/x86/kernel/irq_32.c:148: warning: passing argument 2 of ʽcall_on_stack2ʼ makes integer from pointer without a cast
> arch/x86/kernel/irq_32.c:150: warning: passing argument 2 of ʽcall_on_stack2ʼ makes integer from pointer without a cast
> arch/x86/kernel/irq_32.c:150: warning: passing argument 4 of ʽcall_on_stack2ʼ makes integer from pointer without a cast

Hmm, strange. I don't see that here


CC arch/x86/kernel/irq_32.o
CC arch/x86/kernel/time_32.o

gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)

What compiler are you using? Or did you change anything? (I know you
like to do that)


>> } else
>> #endif
>> - desc->handle_irq(irq, desc);
>> + {
>> + /* AK: Slightly bogus here */
>
> Bogus comment. This applies to both the !4KSTACKS and the overflow of
> the irq stack in the 4KSTACKS case.

The comment refers to that the check here doesn't check the process
stack, but the interrupt stack. In fact if the interrupt stack is near
overflow we should probably just reject the interrupt? Although that
might cause hangs too. Or perhaps just enlarge it [that is now possible
with i386 pda with some effort]. Anyways it is probably not an
interesting case because nested interrupts are rare.

>> + if (overflow)
>
> unlikely(overflow) ?

Doesn't matter really. The whole branch is unlikely.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/