Re: User space out of memory approach

[Andrew Morton]

Andrea Arcangeli <andrea@xxxxxxx> wrote:
>
> > > Can you replace this:
> > > 
> > >         if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) {
> > >                 force_sig(SIGTERM, p);
> > >         } else {
> > >                 force_sig(SIGKILL, p);
> > >         }
> > > 
> > > with this?
> > > 
> > >         force_sig(SIGKILL, p);
> > > 
> > > in mm/oom_kill.c.
> > 
> > Nice. Your suggestion made the error goes away.
> > 
> > We are still testing in order to compare between your OOM Killer and
> > Original OOM Killer.
> 
> Ok, thanks for the confirmation. So my theory was right.
> 
> Basically we've to make this patch, now that you already edited the
> code, can you diff and send a patch that will be the 6/5 in the serie?
> 

I've already queued a patch for this:

--- 25/mm/oom_kill.c~mm-fix-several-oom-killer-bugs-fix	Thu Jan 27 13:56:58 2005
+++ 25-akpm/mm/oom_kill.c	Thu Jan 27 13:57:19 2005
@@ -198,12 +198,7 @@ static void __oom_kill_task(task_t *p)
 	p->time_slice = HZ;
 	p->memdie = 1;
 
-	/* This process has hardware access, be more careful. */
-	if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) {
-		force_sig(SIGTERM, p);
-	} else {
-		force_sig(SIGKILL, p);
-	}
+	force_sig(SIGKILL, p);
 }
 
 static struct mm_struct *oom_kill_task(task_t *p)

However.  This means that we'll now kill off tasks which had hardware
access.  What are the implications of this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/