On Tue 15-03-16 12:43:00, Michal Hocko wrote: > On Tue 15-03-16 20:15:24, Tetsuo Handa wrote: [...] > > Two thread groups sharing the same mm can disable the OOM reaper > > when all threads in the former thread group (which will be chosen > > as an OOM victim by the OOM killer) can immediately call exit_mm() > > via do_exit() (e.g. simply sleeping in killable state when the OOM > > killer chooses that thread group) and some thread in the latter thread > > group is contended on unkillable locks (e.g. inode mutex), due to > > > > p = find_lock_task_mm(tsk); > > if (!p) > > return true; > > > > in __oom_reap_task() and > > > > can_oom_reap = !test_and_set_bit(MMF_OOM_KILLED, &mm->flags); > > > > in oom_kill_process(). The OOM reaper is woken up in order to reap > > the former thread group's memory, but it does nothing on the latter > > thread group's memory because the former thread group can clear its mm > > before the OOM reaper locks its mm. Even if subsequent out_of_memory() > > call chose the latter thread group, the OOM reaper will not be woken up. > > No memory is reaped. We need to queue all thread groups sharing that > > memory if that memory should be reaped. > > Why it wouldn't be enough to wake the oom reaper only for the oom > victims? If the oom reaper races with the victims exit path then > the next round of the out_of_memory will select a different thread > sharing the same mm. And just to prevent from a confusion. I mean waking up also when fatal_signal_pending and we do not really go down to selecting an oom victim. Which would be worth a separate patch on top of course. -- 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>