Re: question about do_IRQ + 4k stacks
On Wed, Mar 30, 2005 at 09:14:22PM -0500, [EMAIL PROTECTED] wrote: > It checks for both process context (system call or kernel thread) or > interrupt context (nested irqs) stack overflows. ok, thanks. so we really only have 3k stacks rather than 4k stacks, right? if any code exceeds 3k stacks and is preempted by an interrupt, we can trigger this check and hang the system as a result (I notice that at least RHEL 4's kernels enable this check by default, not sure about other kernels). Thanks, Terence - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question about do_IRQ + 4k stacks
On Wed, Mar 30, 2005 at 09:14:22PM -0500, [EMAIL PROTECTED] wrote: It checks for both process context (system call or kernel thread) or interrupt context (nested irqs) stack overflows. ok, thanks. so we really only have 3k stacks rather than 4k stacks, right? if any code exceeds 3k stacks and is preempted by an interrupt, we can trigger this check and hang the system as a result (I notice that at least RHEL 4's kernels enable this check by default, not sure about other kernels). Thanks, Terence - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question about do_IRQ + 4k stacks
Terence Ripperda wrote:
I'm investigating some 4k stack issues with our driver, and I noticed
this ordering in do_IRQ:
asmlinkage unsigned int do_IRQ(struct pt_regs regs)
{
...
#ifdef CONFIG_DEBUG_STACKOVERFLOW
/* Debugging check for stack overflow: is there less than 1KB free? */
{
...
}
#endif
...
#ifdef CONFIG_4KSTACKS
for (;;) {
... switch to interrupt stack
}
#endif
Is the intention of this stack overflow check to catch a currently
running kernel thread that's getting low on stack space, or is the
intent to make sure there's enough stack space to handle the incoming
interrupt? if the later, wouldn't you want to potentially switch to
your interrupt stack to be more accurate? (I recognize that often you
will have switched to an empty stack, unless you have nested
interrupts)
It checks for both process context (system call or kernel thread) or
interrupt context (nested irqs) stack overflows.
--
Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
question about do_IRQ + 4k stacks
I'm investigating some 4k stack issues with our driver, and I noticed
this ordering in do_IRQ:
asmlinkage unsigned int do_IRQ(struct pt_regs regs)
{
...
#ifdef CONFIG_DEBUG_STACKOVERFLOW
/* Debugging check for stack overflow: is there less than 1KB free? */
{
...
}
#endif
...
#ifdef CONFIG_4KSTACKS
for (;;) {
... switch to interrupt stack
}
#endif
Is the intention of this stack overflow check to catch a currently
running kernel thread that's getting low on stack space, or is the
intent to make sure there's enough stack space to handle the incoming
interrupt? if the later, wouldn't you want to potentially switch to
your interrupt stack to be more accurate? (I recognize that often you
will have switched to an empty stack, unless you have nested
interrupts)
Thanks,
Terence
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
question about do_IRQ + 4k stacks
I'm investigating some 4k stack issues with our driver, and I noticed
this ordering in do_IRQ:
asmlinkage unsigned int do_IRQ(struct pt_regs regs)
{
...
#ifdef CONFIG_DEBUG_STACKOVERFLOW
/* Debugging check for stack overflow: is there less than 1KB free? */
{
...
}
#endif
...
#ifdef CONFIG_4KSTACKS
for (;;) {
... switch to interrupt stack
}
#endif
Is the intention of this stack overflow check to catch a currently
running kernel thread that's getting low on stack space, or is the
intent to make sure there's enough stack space to handle the incoming
interrupt? if the later, wouldn't you want to potentially switch to
your interrupt stack to be more accurate? (I recognize that often you
will have switched to an empty stack, unless you have nested
interrupts)
Thanks,
Terence
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: question about do_IRQ + 4k stacks
Terence Ripperda wrote:
I'm investigating some 4k stack issues with our driver, and I noticed
this ordering in do_IRQ:
asmlinkage unsigned int do_IRQ(struct pt_regs regs)
{
...
#ifdef CONFIG_DEBUG_STACKOVERFLOW
/* Debugging check for stack overflow: is there less than 1KB free? */
{
...
}
#endif
...
#ifdef CONFIG_4KSTACKS
for (;;) {
... switch to interrupt stack
}
#endif
Is the intention of this stack overflow check to catch a currently
running kernel thread that's getting low on stack space, or is the
intent to make sure there's enough stack space to handle the incoming
interrupt? if the later, wouldn't you want to potentially switch to
your interrupt stack to be more accurate? (I recognize that often you
will have switched to an empty stack, unless you have nested
interrupts)
It checks for both process context (system call or kernel thread) or
interrupt context (nested irqs) stack overflows.
--
Brian Gerst
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
