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

[Michal Hocko <mhocko@suse.cz>]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>