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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/