On 2018/08/28 22:51, Michal Hocko wrote: > On Tue 28-08-18 22:29:56, Tetsuo Handa wrote: > [...] >> The OOM reaper may set MMF_OOM_SKIP without reclaiming any memory (due >> to e.g. mlock()ed memory, shared memory, unable to grab mmap_sem for read). >> We haven't reached to the point where the OOM reaper reclaims all memory >> nor allocating threads wait some more after setting MMF_OOM_SKIP. >> Therefore, this >> >> if (tsk_is_oom_victim(current) && !(oc->gfp_mask & __GFP_NOFAIL)) >> return true; >> >> is the simplest mitigation we can do now. > > But this is adding a mess because you pretend to make a forward progress > even the OOM path didn't do anything at all and rely on another kludge > elsewhere to work. I'm not pretending to make a forward progress. If current thread is an OOM victim, it is guaranteed to make forward progress (unless __GFP_NOFAIL) by failing that allocation attempt after trying memory reserves. The OOM path does not need to do anything at all.
