* [RFC][PATCH] detect & print stack overruns at oops time
@ 2007-08-31 5:28 Eric Sandeen
2007-08-31 16:32 ` Randy Dunlap
2007-09-05 9:30 ` Jarek Poplawski
0 siblings, 2 replies; 7+ messages in thread
From: Eric Sandeen @ 2007-08-31 5:28 UTC (permalink / raw)
To: linux-kernel Mailing List
In thinking about the 4KSTACKS + STACKOVERFLOW problems, I thought
about this - if an oops occurs, explicitly print whether the current
esp is now overrunning the stack, whether the thread has ever overrun
the stack, else print the max stack excursion for the oopsing thread,
if DEBUG_STACK_USAGE is enabled.
1) maybe printing the info for a non-blown stack is not useful..
2) current esp past end of stack can already be deduced, but this
makes it more plain...
3) if the initialization of end_of_stack is problematic for
any reason, it could be removed and the "did we ever overrun"
test could be moved under the DEBUG_STACK_USAGE ifdef
Thoughts? This is a separate problem from the piggy dump_stack()
path, but it seems to me it might be useful in looking at stack-related
oopses when they do occur. With this change, it seems feasible
to turn off DEBUG_STACKOVERFLOW, turn on DEBUG_STACK_USAGE, and just
get the bad news when it's actually happened. :)
Thanks,
-Eric
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Index: linux-2.6.22-rc4/arch/i386/mm/fault.c
===================================================================
--- linux-2.6.22-rc4.orig/arch/i386/mm/fault.c
+++ linux-2.6.22-rc4/arch/i386/mm/fault.c
@@ -525,6 +525,8 @@ no_context:
if (oops_may_print()) {
__typeof__(pte_val(__pte(0))) page;
+ unsigned long *stackend = end_of_stack(tsk);
+ int overrun;
#ifdef CONFIG_X86_PAE
if (error_code & 16) {
@@ -543,6 +545,27 @@ no_context:
printk(KERN_ALERT "BUG: unable to handle kernel paging"
" request");
printk(" at virtual address %08lx\n",address);
+
+ overrun = (unsigned long)stackend - (unsigned long)(®s->esp);
+ if (overrun > 0) {
+ printk(KERN_ALERT "Thread overrunning stack by %d "
+ "bytes\n", overrun);
+ } else {
+#ifdef CONFIG_DEBUG_STACK_USAGE
+ int free;
+ unsigned long *n = stackend;
+ while (!*n)
+ n++;
+ free = (unsigned long)n - (unsigned long)stackend;
+ if (free)
+ printk(KERN_ALERT "Thread used within %d bytes"
+ " of stack end\n", free);
+#endif
+ /* won't catch 100% - stack may have 0s here by chance */
+ if (*stackend) /* was init'd to 0 */
+ printk(KERN_ALERT "Thread overran the stack?\n");
+ }
+
printk(KERN_ALERT " printing eip:\n");
printk("%08lx\n", regs->eip);
Index: linux-2.6.22-rc4/kernel/fork.c
===================================================================
--- linux-2.6.22-rc4.orig/kernel/fork.c
+++ linux-2.6.22-rc4/kernel/fork.c
@@ -163,6 +163,7 @@ static struct task_struct *dup_task_stru
{
struct task_struct *tsk;
struct thread_info *ti;
+ unsigned long *stackend;
prepare_to_copy(orig);
@@ -179,6 +180,8 @@ static struct task_struct *dup_task_stru
*tsk = *orig;
tsk->stack = ti;
setup_thread_stack(tsk, orig);
+ stackend = end_of_stack(tsk);
+ *stackend = 0; /* for overflow detection */
#ifdef CONFIG_CC_STACKPROTECTOR
tsk->stack_canary = get_random_int();
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC][PATCH] detect & print stack overruns at oops time
2007-08-31 5:28 [RFC][PATCH] detect & print stack overruns at oops time Eric Sandeen
@ 2007-08-31 16:32 ` Randy Dunlap
2007-08-31 16:36 ` Eric Sandeen
2007-09-05 9:30 ` Jarek Poplawski
1 sibling, 1 reply; 7+ messages in thread
From: Randy Dunlap @ 2007-08-31 16:32 UTC (permalink / raw)
To: Eric Sandeen; +Cc: linux-kernel Mailing List
On Fri, 31 Aug 2007 00:28:58 -0500 Eric Sandeen wrote:
> Index: linux-2.6.22-rc4/arch/i386/mm/fault.c
> ===================================================================
> --- linux-2.6.22-rc4.orig/arch/i386/mm/fault.c
> +++ linux-2.6.22-rc4/arch/i386/mm/fault.c
> @@ -543,6 +545,27 @@ no_context:
> printk(KERN_ALERT "BUG: unable to handle kernel paging"
> " request");
> printk(" at virtual address %08lx\n",address);
> +
> + overrun = (unsigned long)stackend - (unsigned long)(®s->esp);
> + if (overrun > 0) {
> + printk(KERN_ALERT "Thread overrunning stack by %d "
> + "bytes\n", overrun);
> + } else {
Hi,
Is there something that tells us what <Thread> is doing all of this
bad juju?
> +#ifdef CONFIG_DEBUG_STACK_USAGE
> + int free;
> + unsigned long *n = stackend;
> + while (!*n)
> + n++;
> + free = (unsigned long)n - (unsigned long)stackend;
> + if (free)
> + printk(KERN_ALERT "Thread used within %d bytes"
> + " of stack end\n", free);
> +#endif
> + /* won't catch 100% - stack may have 0s here by chance */
> + if (*stackend) /* was init'd to 0 */
> + printk(KERN_ALERT "Thread overran the stack?\n");
> + }
> +
> printk(KERN_ALERT " printing eip:\n");
> printk("%08lx\n", regs->eip);
>
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC][PATCH] detect & print stack overruns at oops time
2007-08-31 16:32 ` Randy Dunlap
@ 2007-08-31 16:36 ` Eric Sandeen
0 siblings, 0 replies; 7+ messages in thread
From: Eric Sandeen @ 2007-08-31 16:36 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-kernel Mailing List
Randy Dunlap wrote:
> On Fri, 31 Aug 2007 00:28:58 -0500 Eric Sandeen wrote:
>
>> Index: linux-2.6.22-rc4/arch/i386/mm/fault.c
>> ===================================================================
>> --- linux-2.6.22-rc4.orig/arch/i386/mm/fault.c
>> +++ linux-2.6.22-rc4/arch/i386/mm/fault.c
>> @@ -543,6 +545,27 @@ no_context:
>> printk(KERN_ALERT "BUG: unable to handle kernel paging"
>> " request");
>> printk(" at virtual address %08lx\n",address);
>> +
>> + overrun = (unsigned long)stackend - (unsigned long)(®s->esp);
>> + if (overrun > 0) {
>> + printk(KERN_ALERT "Thread overrunning stack by %d "
>> + "bytes\n", overrun);
>> + } else {
>
> Hi,
>
> Is there something that tells us what <Thread> is doing all of this
> bad juju?
Sure, the rest of the oops report will.
-Eric
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC][PATCH] detect & print stack overruns at oops time
2007-08-31 5:28 [RFC][PATCH] detect & print stack overruns at oops time Eric Sandeen
2007-08-31 16:32 ` Randy Dunlap
@ 2007-09-05 9:30 ` Jarek Poplawski
2007-09-05 12:51 ` Eric Sandeen
1 sibling, 1 reply; 7+ messages in thread
From: Jarek Poplawski @ 2007-09-05 9:30 UTC (permalink / raw)
To: Eric Sandeen; +Cc: linux-kernel Mailing List
On 31-08-2007 07:28, Eric Sandeen wrote:
> In thinking about the 4KSTACKS + STACKOVERFLOW problems, I thought
...
> Thoughts? This is a separate problem from the piggy dump_stack()
> path, but it seems to me it might be useful in looking at stack-related
> oopses when they do occur. With this change, it seems feasible
> to turn off DEBUG_STACKOVERFLOW, turn on DEBUG_STACK_USAGE, and just
> get the bad news when it's actually happened. :)
Very good idea, but maybe, at least for some time, it should be with
ifdef CONFIG_4KSTACKS, to check if it's really needed if some other
similar checks also set.
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>
> Index: linux-2.6.22-rc4/arch/i386/mm/fault.c
> ===================================================================
> --- linux-2.6.22-rc4.orig/arch/i386/mm/fault.c
> +++ linux-2.6.22-rc4/arch/i386/mm/fault.c
> @@ -525,6 +525,8 @@ no_context:
>
> if (oops_may_print()) {
> __typeof__(pte_val(__pte(0))) page;
> + unsigned long *stackend = end_of_stack(tsk);
> + int overrun;
>
> #ifdef CONFIG_X86_PAE
> if (error_code & 16) {
> @@ -543,6 +545,27 @@ no_context:
> printk(KERN_ALERT "BUG: unable to handle kernel paging"
> " request");
> printk(" at virtual address %08lx\n",address);
> +
> + overrun = (unsigned long)stackend - (unsigned long)(®s->esp);
> + if (overrun > 0) {
> + printk(KERN_ALERT "Thread overrunning stack by %d "
> + "bytes\n", overrun);
> + } else {
> +#ifdef CONFIG_DEBUG_STACK_USAGE
> + int free;
> + unsigned long *n = stackend;
> + while (!*n)
> + n++;
> + free = (unsigned long)n - (unsigned long)stackend;
> + if (free)
Maybe there should be some min 'free' and max number of printks? There
could be also considered if, with some minimal values of 'free', prink
is the best thing we can do before stack overruning?
> + printk(KERN_ALERT "Thread used within %d bytes"
> + " of stack end\n", free);
> +#endif
> + /* won't catch 100% - stack may have 0s here by chance */
> + if (*stackend) /* was init'd to 0 */
Isn't a MAGIC number better for this? (Then of course above n should
start a bit higher.)
Regards,
Jarek P.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC][PATCH] detect & print stack overruns at oops time
2007-09-05 9:30 ` Jarek Poplawski
@ 2007-09-05 12:51 ` Eric Sandeen
2007-09-05 14:19 ` Jarek Poplawski
0 siblings, 1 reply; 7+ messages in thread
From: Eric Sandeen @ 2007-09-05 12:51 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: linux-kernel Mailing List
Jarek Poplawski wrote:
> On 31-08-2007 07:28, Eric Sandeen wrote:
>> In thinking about the 4KSTACKS + STACKOVERFLOW problems, I thought
> ...
>> Thoughts? This is a separate problem from the piggy dump_stack()
>> path, but it seems to me it might be useful in looking at stack-related
>> oopses when they do occur. With this change, it seems feasible
>> to turn off DEBUG_STACKOVERFLOW, turn on DEBUG_STACK_USAGE, and just
>> get the bad news when it's actually happened. :)
>
> Very good idea, but maybe, at least for some time, it should be with
> ifdef CONFIG_4KSTACKS, to check if it's really needed if some other
> similar checks also set.
Hi Jarek - thanks for the comments.
I don't see much, if any, runtime impact to having it on all the time,
except maybe the end-of-stack zeroing, which would have at least some
impact. Everything except that single " = 0;" only runs if you've
already oopsed... I'd hate to clutter it with #ifdefs unless there's a
good reason.
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>>
>> Index: linux-2.6.22-rc4/arch/i386/mm/fault.c
>> ===================================================================
>> --- linux-2.6.22-rc4.orig/arch/i386/mm/fault.c
>> +++ linux-2.6.22-rc4/arch/i386/mm/fault.c
>> @@ -525,6 +525,8 @@ no_context:
>>
>> if (oops_may_print()) {
>> __typeof__(pte_val(__pte(0))) page;
>> + unsigned long *stackend = end_of_stack(tsk);
>> + int overrun;
>>
>> #ifdef CONFIG_X86_PAE
>> if (error_code & 16) {
>> @@ -543,6 +545,27 @@ no_context:
>> printk(KERN_ALERT "BUG: unable to handle kernel paging"
>> " request");
>> printk(" at virtual address %08lx\n",address);
>> +
>> + overrun = (unsigned long)stackend - (unsigned long)(®s->esp);
>> + if (overrun > 0) {
>> + printk(KERN_ALERT "Thread overrunning stack by %d "
>> + "bytes\n", overrun);
>> + } else {
>> +#ifdef CONFIG_DEBUG_STACK_USAGE
>> + int free;
>> + unsigned long *n = stackend;
>> + while (!*n)
>> + n++;
>> + free = (unsigned long)n - (unsigned long)stackend;
>> + if (free)
>
> Maybe there should be some min 'free' and max number of printks? There
> could be also considered if, with some minimal values of 'free', prink
> is the best thing we can do before stack overruning?
You mean, don't print unless the free value is in some range? My
thought was, if you always print *something*, then you know for sure
you're looking at an oops from a kernel with this code in place.
Though, if "all's well" I suppose the bytes remaining isn't so
important; it would really be enough to just say:
if (!(*stackend))
printk("Thread stayed within stack space\n");
else
printk("Thread overran stack\n");
>> + printk(KERN_ALERT "Thread used within %d bytes"
>> + " of stack end\n", free);
>> +#endif
>> + /* won't catch 100% - stack may have 0s here by chance */
>> + if (*stackend) /* was init'd to 0 */
>
> Isn't a MAGIC number better for this? (Then of course above n should
> start a bit higher.)
I thought about that, though really *anything* could legitimately be on
the stack, so I guess it's a question of probabilities. And, "0" is
compatible with CONFIG_DEBUG_STACK_USAGE, which sets the the whole stack
to 0 and uses that to detect max stack excursion... I guess that option
could probably be tweaked to zero the whole stack, and then also set the
last position to something magic (0xDEAD57AC - deadstack?), and check
for that as well. (I had thought about making helper functions for
DEBUG_STACK_OVERFLOW, right now the checks are open coded in a few places).
Thanks,
-Eric
>
> Regards,
> Jarek P.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC][PATCH] detect & print stack overruns at oops time
2007-09-05 12:51 ` Eric Sandeen
@ 2007-09-05 14:19 ` Jarek Poplawski
2007-09-05 14:29 ` Jarek Poplawski
0 siblings, 1 reply; 7+ messages in thread
From: Jarek Poplawski @ 2007-09-05 14:19 UTC (permalink / raw)
To: Eric Sandeen; +Cc: linux-kernel Mailing List
On Wed, Sep 05, 2007 at 07:51:16AM -0500, Eric Sandeen wrote:
> Jarek Poplawski wrote:
> > On 31-08-2007 07:28, Eric Sandeen wrote:
> >> In thinking about the 4KSTACKS + STACKOVERFLOW problems, I thought
> > ...
> >> Thoughts? This is a separate problem from the piggy dump_stack()
> >> path, but it seems to me it might be useful in looking at stack-related
> >> oopses when they do occur. With this change, it seems feasible
> >> to turn off DEBUG_STACKOVERFLOW, turn on DEBUG_STACK_USAGE, and just
> >> get the bad news when it's actually happened. :)
> >
> > Very good idea, but maybe, at least for some time, it should be with
> > ifdef CONFIG_4KSTACKS, to check if it's really needed if some other
> > similar checks also set.
>
> Hi Jarek - thanks for the comments.
>
> I don't see much, if any, runtime impact to having it on all the time,
> except maybe the end-of-stack zeroing, which would have at least some
> impact. Everything except that single " = 0;" only runs if you've
> already oopsed... I'd hate to clutter it with #ifdefs unless there's a
> good reason.
I've meant: with 4KSTACKS there is probably no doubt it's needed, even
at the cost of some impact, which by the way could be more tested (and
there is a way to turn it off for, maybe, some conflicts). But, if you
checked it all enough and think such 'debugging' time is not necessary
then of course, without ifdefs it looks nicer.
>
>
> >> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> >>
> >> Index: linux-2.6.22-rc4/arch/i386/mm/fault.c
> >> ===================================================================
> >> --- linux-2.6.22-rc4.orig/arch/i386/mm/fault.c
> >> +++ linux-2.6.22-rc4/arch/i386/mm/fault.c
> >> @@ -525,6 +525,8 @@ no_context:
> >>
> >> if (oops_may_print()) {
> >> __typeof__(pte_val(__pte(0))) page;
> >> + unsigned long *stackend = end_of_stack(tsk);
> >> + int overrun;
> >>
> >> #ifdef CONFIG_X86_PAE
> >> if (error_code & 16) {
> >> @@ -543,6 +545,27 @@ no_context:
> >> printk(KERN_ALERT "BUG: unable to handle kernel paging"
> >> " request");
> >> printk(" at virtual address %08lx\n",address);
> >> +
> >> + overrun = (unsigned long)stackend - (unsigned long)(®s->esp);
> >> + if (overrun > 0) {
> >> + printk(KERN_ALERT "Thread overrunning stack by %d "
> >> + "bytes\n", overrun);
> >> + } else {
> >> +#ifdef CONFIG_DEBUG_STACK_USAGE
> >> + int free;
> >> + unsigned long *n = stackend;
> >> + while (!*n)
> >> + n++;
> >> + free = (unsigned long)n - (unsigned long)stackend;
> >> + if (free)
> >
> > Maybe there should be some min 'free' and max number of printks? There
> > could be also considered if, with some minimal values of 'free', prink
> > is the best thing we can do before stack overruning?
>
> You mean, don't print unless the free value is in some range? My
> thought was, if you always print *something*, then you know for sure
> you're looking at an oops from a kernel with this code in place.
> Though, if "all's well" I suppose the bytes remaining isn't so
> important; it would really be enough to just say:
>
> if (!(*stackend))
> printk("Thread stayed within stack space\n");
> else
> printk("Thread overran stack\n");
>
OOPS! I didn't read the code around enough. Since it's one time event
there should be no problem of too much repeating, sorry! But, there
is probably still a question: if such a printk can overrun the stack
and possibly stuck the machine I would prefer to have some log on the
disk or possibility of sysrq or ctrl-alt-del than to write by hand or
take a picture with this one printk more... Of course, if I missed it
again, and there is choice or risk, then - no question & all correct.
>
> >> + printk(KERN_ALERT "Thread used within %d bytes"
> >> + " of stack end\n", free);
> >> +#endif
> >> + /* won't catch 100% - stack may have 0s here by chance */
> >> + if (*stackend) /* was init'd to 0 */
> >
> > Isn't a MAGIC number better for this? (Then of course above n should
> > start a bit higher.)
>
> I thought about that, though really *anything* could legitimately be on
> the stack, so I guess it's a question of probabilities. And, "0" is
> compatible with CONFIG_DEBUG_STACK_USAGE, which sets the the whole stack
> to 0 and uses that to detect max stack excursion... I guess that option
> could probably be tweaked to zero the whole stack, and then also set the
> last position to something magic (0xDEAD57AC - deadstack?), and check
> for that as well. (I had thought about making helper functions for
> DEBUG_STACK_OVERFLOW, right now the checks are open coded in a few places).
IMHO 0 is the worst possible choice for this - I think it's used far
more often than others, there is only a question to stay compatible
with other debug checkers (or ifdef from them...), but anything else
looks much more credible to me.
Thanks,
Jarek P.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC][PATCH] detect & print stack overruns at oops time
2007-09-05 14:19 ` Jarek Poplawski
@ 2007-09-05 14:29 ` Jarek Poplawski
0 siblings, 0 replies; 7+ messages in thread
From: Jarek Poplawski @ 2007-09-05 14:29 UTC (permalink / raw)
To: Eric Sandeen; +Cc: linux-kernel Mailing List
On Wed, Sep 05, 2007 at 04:19:23PM +0200, Jarek Poplawski wrote:
...
> again, and there is choice or risk, then - no question & all correct.
Should be:
again, and there is no choice or risk, then - no question & all correct.
Jarek P.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-09-05 14:27 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-31 5:28 [RFC][PATCH] detect & print stack overruns at oops time Eric Sandeen
2007-08-31 16:32 ` Randy Dunlap
2007-08-31 16:36 ` Eric Sandeen
2007-09-05 9:30 ` Jarek Poplawski
2007-09-05 12:51 ` Eric Sandeen
2007-09-05 14:19 ` Jarek Poplawski
2007-09-05 14:29 ` Jarek Poplawski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox