On 2018/07/21 5:19, David Rientjes wrote: > 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. > Why [PATCH 2/2] in https://marc.info/?l=linux-mm&m=153119509215026&w=4 does not solve your problem?
