Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

[Michal Hocko <mhocko@kernel.org>]

On Tue 24-04-18 13:01:03, David Rientjes wrote:
> On Tue, 24 Apr 2018, Michal Hocko wrote:
> 
> > Is there any reason why we cannot simply call __oom_reap_task_mm as we
> > have it now? mmap_sem for read shouldn't fail here because this is the
> > last reference of the mm and we are past the ksm and khugepaged
> > synchronizations. So unless my jed laged brain fools me the patch should
> > be as simple as the following (I haven't tested it at all).
> > 
> 
> I wanted to remove all per task checks because they are now irrelevant: 
> this would be the first dependency that exit_mmap() has on any 
> task_struct, which isn't intuitive -- we simply want to exit the mmap.  
> There's no requirement that current owns the mm other than this. 

There is no such requirement in the __oom_reap_task_mm. The given task
is used for reporting purposes.

> I wanted 
> to avoid the implicit dependency on MMF_OOM_SKIP and make it explicit in 
> the exit path to be matched with the oom reaper.

Well, I find it actually better that the code is not explicit about
MMF_OOM_SKIP. The whole thing happens in the oom proper which should be
really preferable. The whole synchronization is then completely
transparent to the oom (including the oom lock etc).

> I didn't want anything 
> additional printed to the kernel log about oom reaping unless the 
> oom_reaper actually needed to intervene, which is useful knowledge outside 
> of basic exiting.

Can we shave all those parts as follow ups and make the fix as simple as
possible?
 
> My patch has passed intensive testing on both x86 and powerpc, so I'll ask 
> that it's pushed for 4.17-rc3.  Many thanks to Tetsuo for the suggestion 
> on calling __oom_reap_task_mm() from exit_mmap().

Yeah, but your patch does have a problem with blockable mmu notifiers
IIUC.
-- 
Michal Hocko
SUSE Labs