OOM-killer prevention for master kdeinit process

[Lubos Lunak]

On Thursday 03 August 2006 00:17, Dirk Mueller wrote:
> On Wednesday, 2. August 2006 23:21, Lubos Lunak wrote:
> >  Ah, damn, of course it is inherited :(. So the adjustment needs to be
> > reset right after forking. Hmm, I'm not sure we want kdeinit to stay
> > setuid for so long, so I guess that means another setuid helper
>
> It is getting silly. Perhaps we should rather send our brave kernel
> developers a patch for that.

 My turn or your turn :) ? Last time I upset Andrea IIRC.

 And yes, it is silly, but even if you somehow magically now manage to get it 
fixed, it's still going to take ages. Ok, I know we've lived with this for 
long, but I'd like to get this fixed now if possible.

> It doesn't make any sense to prevent 
> increasing our own oom score (integer overflows excluded). It also doesn't
> make sense for negative oom adjustment score to be inherited to childs.
> Also, I think there is a way to allow non-root processes to negate their
> oom score in a certain range without causing a problem, which would totally
> remove the need for this silly suid wrapper.
>
> > that helper will need some checks to make sure it cannot be misused? Do
> > we have already something similar I could base this on?
...

> However, what we have to ensure is that kdeinit itself, when launched via
> start_kdeinit, does not process any command line arguments or config file
> options that would cause it to launch code / processes directly without
> dropping the OOM killing score. Thats a bit non trivial to achieve, given
> the number of libraries kdeinit links against. Therefore, this helper is
> really really hard to get right.

 Actually, thinking more about it, it's perhaps rather simple simple to get 
right. Currently the situation is like this: You get OOM, your klauncher, 
kwin and who knows what else are more or less guaranteed to be killed -> kiss 
your KDE session good-bye. Since the helper would only set the adjustment to 
normal value and then immediately drop privileges, the only thing that could 
go wrong would be having some process with default oom_adj set to normal. 
Also, some unwanted launching of something from kdeinit with the adjustment 
inherited (even though I don't quite see how that could happen in practice) 
would just at worst result in a process that wouldn't get killed by the 
OOM-killer in the unlikely case it misbehaves, causing the OOM-killer go 
nuts - which is exactly what happens now. Or am I missing something?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/