Re: [patch] oom-killer sysrq-f fix

[Coywolf Qi Hunt <coywolf@lovecn.org>]

Andrew Morton wrote:
> Coywolf Qi Hunt <coywolf@sosdg.org> 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 <coywolf@lovecn.org>
>>
>>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.