> > > I think that maybe it's good to put a:
> > > WARN_ON(!mm);
> > > but a BUG_ON or without this patch, the kernel will halt, even if the
> > > problem is not so severe.
> >
> > Patching up the kernel hiding things that must not happen is not the way
> > to go. All kernel bugs are severe (as you just showed us!). Adding extra
> > checks like your original patch did may even cause much more harm
> > because it may hide other problems causing silent problems.
>
> If I understand Andre correctly, his patch will prevent infinite recursion
> in the oops path - if some process oopses after having run exit_mm().
>
> If so then it's a reasonable debugging aid. Although there might be better
> places to do it, such as
>
> if (!current->i_tried_to_exit++)
> return;
>
> in do_exit(). Dunno.
This patch is very crude but it is quite resistant to recursive faults
in do_exit(), survives the LTP hammering I've given it. The problem is
not knowing where in the previous path it broke down so I'd rather just
leave it lying around and try a graceful reset/power off. But if anyone
has a better suggestion than the msleep() I'm all ears but this area is
sensitive.
Where is that anonymous patch hot-line...
Index: mm/kernel/exit.c
===================================================================
--- mm.orig/kernel/exit.c 2005-05-04 22:24:57.000000000 +0200
+++ mm/kernel/exit.c 2005-05-04 23:19:08.000000000 +0200
@@ -29,6 +29,7 @@
#include <linux/perfctr.h>
#include <linux/syscalls.h>
#include <linux/signal.h>
+#include <linux/delay.h>
#include <asm/uaccess.h>
#include <asm/unistd.h>
@@ -797,6 +798,14 @@
ptrace_notify((PTRACE_EVENT_EXIT << 8) | SIGTRAP);
}
+ /* We're taking recursive faults originating here in do_exit. Safest
+ * is to just leave this task alone and wait for reboot. */
+ if (tsk->flags & PF_EXITING) {
+ printk(KERN_ALERT "\nFixing recursive fault but reboot is needed!\n");
+ for (;;)
+ msleep(1000 * 10);
+ }
+
tsk->flags |= PF_EXITING;
/*
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
