Re: [RFC PATCH] oom: Don't count on mm-less current process.

Michal Hocko
2014-12-23T13:43:12Z

On Tue 23-12-14 22:20:57, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 23-12-14 22:00:52, Tetsuo Handa wrote:
[...]
> > > Then, I think deferring SIGKILL might widen race window for abusing TIF_MEMDIE.
> >
> > How would it abuse the flag? The OOM victim has to die and if it needs
> > to allocate then we have to allow it to do so otherwise the whole
> > exercise was pointless. fatal_signal_pending check is not so widespread
> > in the kernel that the task would notice it immediately.
>
> I'm talking about possible delay between TIF_MEMDIE was set on the victim
> and SIGKILL is delivered to the victim.

I can read what you wrote. You are just ignoring my questions it seems
because I haven't got any reason _why it matters_. My point was that the
victim might be looping in the kernel and doing other allocations until
it notices it has fatal_signal_pending and bail out. So the delay
between setting the flag and sending the signal is not that important
AFAICS.

> Why the victim has to die before receiving SIGKILL?

It has to die to resolve the current OOM condition. I haven't written
anything about dying before receiving SIGKILL.

> The victim can access memory reserves until SIGKILL is delivered,
> can't it?

And why does that matter? It would have to do such an allocation anyway
because it wouldn't proceed without it... And the only difference
between having the flag and not having it is that the allocation has
higher chance to succeed with the flag so it will not trigger the OOM
killer again right away. See the point or am I missing something here?

--
Michal Hocko
SUSE Labs