OOM-killer prevention for master kdeinit process

[Oswald Buddenhagen]

On Mon, Aug 07, 2006 at 11:18:29AM +0200, Lubos Lunak wrote:
> On Friday 04 August 2006 22:15, Oswald Buddenhagen wrote:
> > On Fri, Aug 04, 2006 at 09:27:22PM +0200, Thomas Zander wrote:
> > > On Friday 4 August 2006 20:59, Oswald Buddenhagen wrote:
> > > > >  Any objections to commit?
> > > >
> > > > yes. you are essentially creating a blank check for any application to
> > > > "escape" oom-killing,
> > >
> > > Could you explain why changing this one process would have that effect?
> >
> > uhm, well, actually, it's not that bad, as EXECUTE is hard-coded, making
> > it effectively my second case.
> 
>  What second case, setuid KApplication? There's no setuid KApplication. Or do 
> you still see some other problem with it?
> 
no, *that* second case (the real one, like 1 2 ...):
> > the next idea would be letting the actual kdeinit spawn the empowered
> > helper and drop setuid, but that doesn't work, either, as the
> > de-priviledged kdeinit would be exposed to memory image attacks by the
> > user.

> > otoh, hard-coding paths in binaries is another thing that *should* be
> > avoided (not that *yet another* case would actually hurt ...).
> 
>  Stupid OOM-killer should be probably avoided more.
> 
might well be. ;)
but the point is, that having it in a separate binary doesn't exactly
buy us a particular lot, unless it simplifies the surrounding logic.

btw, i think your reset_oom_protect() implementation has a race
condition: the write may have been already read and the process
SIGCONT-ed before you even SIGSTOP yourself. you should use sigprocmask
and sigsuspend or something.
fwiw, kill(getpid(), SIG) should be raise(SIG).

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.