On Tue 10-07-18 14:12:28, David Rientjes wrote: > On Tue, 10 Jul 2018, David Rientjes wrote: > > > I think it's better, thanks. However, does it address the question about > > why __oom_reap_task_mm() needs oom_lock protection? Perhaps it would be > > helpful to mention synchronization between reaping triggered from > > oom_reaper and by exit_mmap(). > > > > Actually, can't we remove the need to take oom_lock in exit_mmap() if > __oom_reap_task_mm() can do a test and set on MMF_UNSTABLE and, if already > set, bail out immediately? I think we do not really depend on oom_lock anymore in __oom_reap_task_mm. The race it was original added for (mmget_not_zero vs. exit path) is no longer a problem. I didn't really get to evaluate it deeper though. There are just too many things going on in parallel. Tetsuo was proposing some patches to remove the lock but those patches had some other problems. If we have a simple patch to remove the oom_lock from the oom reaper then I will review it. I am not sure I can come up with a patch myself in few days. -- Michal Hocko SUSE Labs
