lkml.org 
[lkml]   [2018]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch v3] mm, oom: fix unnecessary killing of additional processes
From
Date
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?

\
 
 \ /
  Last update: 2018-07-20 22:49    [W:0.066 / U:3.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site