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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>