On 2018/07/20 17:41, David Rientjes 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 ) and my cleanup patch ( [PATCH 1/2] at https://marc.info/?l=linux-mm&m=153119509215026&w=4 ) on top of linux.git . And please reply how was the result, for I'm currently asking Roman whether we can apply these patches before applying the cgroup-aware OOM killer.
