On Fri, 20 Jul 2018, Tetsuo Handa wrote: > > Absent oom_lock serialization, this is exactly working as intended. You > > could argue that once the thread has reached exit_mmap() and begins oom > > reaping that it should be allowed to finish before the oom reaper declares > > MMF_OOM_SKIP. That could certainly be helpful, I simply haven't > > encountered a usecase where it were needed. Or, we could restart the oom > > expiration when MMF_UNSTABLE is set and deem that progress is being made > > so it give it some extra time. In practice, again, we haven't seen this > > needed. But either of those are very easy to add in as well. Which would > > you prefer? > > I don't think we need to introduce user-visible knob interface (even if it is > in > debugfs), for I think that my approach can solve your problem. Please try OOM > lockup > (CVE-2016-10723) mitigation patch ( > https://marc.info/?l=linux-mm&m=153112243424285&w=4 )
The issue I am fixing has nothing to do with contention on oom_lock, it has to do with the inability of the oom reaper to free memory for one or more of several reasons: mlock, blockable mmus, ptes, mm->mmap_sem contention, and then the setting of MMF_OOM_SKIP to choose another victim before the original victim even reaches exit_mmap(). Thus, removing oom_lock from exit_mmap() will not fix this issue. I agree that oom_lock can be removed from exit_mmap() and it would be helpful to do so, and may address a series of problems that we have yet to encounter, but this would not fix the almost immediate setting of MMF_OOM_SKIP that occurs with minimal memory freeing due to the oom reaper.
