The attached patch adds a couple of extra hooks by which kgdb or an equivalent
gdbstub can catch bad_page() and panic() invocations.
Signed-Off-By: [email protected]
---
diffstat kgdb-hooks-2610rc1mm3.diff
include/asm-generic/bug.h | 8 ++++++++
kernel/panic.c | 1 +
mm/page_alloc.c | 1 +
3 files changed, 10 insertions(+)
diff -uNrp /warthog/kernels/linux-2.6.10-rc1-mm3/include/asm-generic/bug.h linux-2.6.10-rc1-mm3-frv/include/asm-generic/bug.h
--- /warthog/kernels/linux-2.6.10-rc1-mm3/include/asm-generic/bug.h 2004-10-19 10:42:12.000000000 +0100
+++ linux-2.6.10-rc1-mm3-frv/include/asm-generic/bug.h 2004-11-05 14:13:04.327459964 +0000
@@ -18,6 +18,10 @@
} while (0)
#endif
+#ifndef HAVE_ARCH_KGDB_BAD_PAGE
+#define kgdb_bad_page(page) do {} while(0)
+#endif
+
#ifndef HAVE_ARCH_BUG_ON
#define BUG_ON(condition) do { if (unlikely((condition)!=0)) BUG(); } while(0)
#endif
@@ -31,4 +35,8 @@
} while (0)
#endif
+#ifndef HAVE_ARCH_KGDB_RAISE
+#define kgdb_raise(signr) do {} while(0)
+#endif
+
#endif
diff -uNrp /warthog/kernels/linux-2.6.10-rc1-mm3/kernel/panic.c linux-2.6.10-rc1-mm3-frv/kernel/panic.c
--- /warthog/kernels/linux-2.6.10-rc1-mm3/kernel/panic.c 2004-11-05 13:15:51.000000000 +0000
+++ linux-2.6.10-rc1-mm3-frv/kernel/panic.c 2004-11-05 14:13:04.528442988 +0000
@@ -73,6 +73,7 @@ NORET_TYPE void panic(const char * fmt,
vsnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
printk(KERN_EMERG "Kernel panic - not syncing: %s\n",buf);
+ kgdb_raise(SIGABRT);
bust_spinlocks(0);
/* If we have crashed, perform a kexec reboot, for dump write-out */
diff -uNrp /warthog/kernels/linux-2.6.10-rc1-mm3/mm/page_alloc.c linux-2.6.10-rc1-mm3-frv/mm/page_alloc.c
--- /warthog/kernels/linux-2.6.10-rc1-mm3/mm/page_alloc.c 2004-11-05 13:15:52.000000000 +0000
+++ linux-2.6.10-rc1-mm3-frv/mm/page_alloc.c 2004-11-05 14:13:04.654432347 +0000
@@ -88,6 +89,7 @@ static void bad_page(const char *functio
page->mapping, page_mapcount(page), page_count(page));
printk(KERN_EMERG "Backtrace:\n");
dump_stack();
+ kgdb_bad_page(page);
printk(KERN_EMERG "Trying to fix it up, but a reboot is needed\n");
page->flags &= ~(1 << PG_private |
1 << PG_locked |
> > The attached patch adds a couple of extra hooks by which kgdb or an
> > equivalent gdbstub can catch bad_page() and panic() invocations.
>
> What stub are you using that doesn't catch these?
FRV.
David
On Mon, Nov 08, 2004 at 02:32:41PM +0000, [email protected] wrote:
> The attached patch adds a couple of extra hooks by which kgdb or an equivalent
> gdbstub can catch bad_page() and panic() invocations.
What stub are you using that doesn't catch these?
--
Tom Rini
http://gate.crashing.org/~trini/
[email protected] wrote:
>
> The attached patch adds a couple of extra hooks by which kgdb or an equivalent
> gdbstub can catch bad_page() and panic() invocations.
Tom is valiantly flogging his way through a generic KGDB implementation. I
think it would be better to push ahead with that and to not put into
generic code hooks which are specific to one arch's kgdb implementation.
Andrew Morton wrote:
> [email protected] wrote:
>
>>The attached patch adds a couple of extra hooks by which kgdb or an equivalent
>>gdbstub can catch bad_page() and panic() invocations.
>
>
> Tom is valiantly flogging his way through a generic KGDB implementation. I
> think it would be better to push ahead with that and to not put into
> generic code hooks which are specific to one arch's kgdb implementation.
>
IMNSHO the trap should be in dump_stack(). That way it catches a bunch of
things all at once.
Also, panic has a notify option that kgdb should use just like everybody else.
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
On Tue, Nov 09, 2004 at 03:29:28PM -0800, George Anzinger wrote:
> Andrew Morton wrote:
> >[email protected] wrote:
> >
> >>The attached patch adds a couple of extra hooks by which kgdb or an
> >>equivalent
> >>gdbstub can catch bad_page() and panic() invocations.
> >
> >
> >Tom is valiantly flogging his way through a generic KGDB implementation. I
> >think it would be better to push ahead with that and to not put into
> >generic code hooks which are specific to one arch's kgdb implementation.
>
> IMNSHO the trap should be in dump_stack(). That way it catches a bunch of
> things all at once.
The hard question is how to do this cleanly. Perhaps changing things
slightly so that lib/dump_stack.c provides the 'true' dump_stack() (or
moving it to kernel/dump_stack.c) which calls a notify chain and then
arch_dump_stack() ?
> Also, panic has a notify option that kgdb should use just like everybody
> else.
This is a good idea, I'm surprised we didn't already do, so I've just
done it.
--
Tom Rini
http://gate.crashing.org/~trini/