Andrew Morton wrote:
Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote:
Recent make-sysrq-f-call-oom_kill.patch calls oom-killer in interrupt context,
thus results into panic. This patch fixes out_of_memory() to avoid schedule
when in interrupt context.
Coywolf
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
diff -pruN 2.6.12-rc1-mm2/mm/oom_kill.c 2.6.12-rc1-mm2-cy/mm/oom_kill.c
--- 2.6.12-rc1-mm2/mm/oom_kill.c 2005-03-03 17:12:18.000000000 +0800
+++ 2.6.12-rc1-mm2-cy/mm/oom_kill.c 2005-03-25 08:07:19.000000000 +0800
@@ -20,6 +20,7 @@
#include <linux/swap.h>
#include <linux/timex.h>
#include <linux/jiffies.h>
+#include <linux/hardirq.h>
/* #define DEBUG */
@@ -283,6 +284,9 @@ retry:
if (mm)
mmput(mm);
+ if (in_interrupt())
+ return;
That'll make the whole feature a no-op, won't it?
It won't be a no-op. I have tested it. It works well.
I pressed sysrq-f, loging bash got killed and I had to re-login.
The thing needs to be moved into process context via schedule_work(). I
haven't got around to it yet.
I don't think schedule_work() is a good option here. Since sysrq-f is
emergent,
we just let oom-killer send SIGKILL in interrupt context and return.
We needn't send SIGKILL in a process context. That'll be slow and [events] may
got delayed.
-
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/
