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

From: David Rientjes
Date: Tue Apr 24 2018 - 16:22:55 EST


On Tue, 24 Apr 2018, Michal Hocko wrote:

> > 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.
>

And tracing, which is pointless. And it unnecessarily spams the kernel
log for basic exiting.

> > 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).
>

It's already done in exit_mmap(). I'm not changing

> > 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?
>

It is as simple as possible. It is not doing any unnecessary locking or
checks that the exit path does not need to do for the sake of a smaller
patch. The number of changed lines in the patch is not what I'm
interested in, I am interested in something that is stable, something that
works, doesn't add additional (and unnecessary locking), and doesn't
change around what function sets what bit when called from what path.

> > 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.

What on earth are you talking about? exit_mmap() does
mmu_notifier_release(). There are no blockable mmu notifiers.