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

Michal Hocko
2014-12-23T14:57:28Z

On Tue 23-12-14 23:11:01, Tetsuo Handa wrote:
[...]
> (1) P2 is sleeping at sleep(10).
> (2) P1 triggers the OOM killer and P2 is chosen.
> (3) The OOM killer sets TIF_MEMDIE on P2.
> (4) P2 wakes up as sleep(10) expired.
> (5) P2 calls read().
> (6) P2 triggers page fault inside read().
> (7) P2 allocates from memory reserves for handling page fault.
> (8) The OOM killer sends SIGKILL to P2.
> (9) P2 receives SIGKILL after all memory reserves were
> allocated for handling page fault.
> (10) P2 starts steps for die, but memory reserves may be
> already empty.

How is that any different from any other task which allocates with
TIF_MEMDIE already set and fatal_signal_pending without checking for
the later?

> My worry:
>
> More the delay between (3) and (8) becomes longer (e.g. 30 seconds
> for an overdone case), more likely to cause memory reserves being
> consumed before (9). If (3) and (8) are reversed, P2 will notice
> fatal_signal_pending() and bail out before allocating a lot of
> memory from memory reserves.

And my suspicion is that this has never been a real problem and I really
do not like to fiddle with the code for non-existing problems. If
you are sure that the reverse order is correct and doesn't cause any
other issues then you are free to send a separate patch with a proper
justification. The patch I've posted fixes a different problem and
putting more stuff in it is just not right! I really hate how you
conflate different issues all the time, TBH.

Thanks!
--
Michal Hocko
SUSE Labs