From 6b935b08409a05d70f2888a9682d5c20fcd553c3 Mon Sep 17 00:00:00 2001 From: Robin Getz Date: Thu, 5 Nov 2009 15:44:44 +0000 Subject: [PATCH] --- yaml --- r: 177290 b: refs/heads/master c: dbc5e6989e2261c965bae5269d26ed1641e1534c h: refs/heads/master v: v3 --- [refs] | 2 +- trunk/arch/blackfin/kernel/traps.c | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/[refs] b/[refs] index 10163c144284..e5daeebaa729 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: e92d32fcb9925884a0ad9e1ad8f10d837d7de7a6 +refs/heads/master: dbc5e6989e2261c965bae5269d26ed1641e1534c diff --git a/trunk/arch/blackfin/kernel/traps.c b/trunk/arch/blackfin/kernel/traps.c index 89835ac58a8a..427294c47f1b 100644 --- a/trunk/arch/blackfin/kernel/traps.c +++ b/trunk/arch/blackfin/kernel/traps.c @@ -119,6 +119,15 @@ static void decode_address(char *buf, unsigned long address) return; } + /* + * Don't walk any of the vmas if we are oopsing, it has been known + * to cause problems - corrupt vmas (kernel crashes) cause double faults + */ + if (oops_in_progress) { + strcat(buf, "/* kernel dynamic memory (maybe user-space) */"); + return; + } + /* looks like we're off in user-land, so let's walk all the * mappings of all our processes and see if we can't be a whee * bit more specific