lkml.org 
[lkml]   [2017]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] oom_reaper: close race without using oom_lock
On Sat 22-07-17 00:18:48, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > > If we ignore MMF_OOM_SKIP once, we can avoid sequence above.
> >
> > But we set MMF_OOM_SKIP _after_ the process lost its address space (well
> > after the patch which allows to race oom reaper with the exit_mmap).
> >
> > >
> > > Process-1 Process-2
> > >
> > > Takes oom_lock.
> > > Fails get_page_from_freelist().
> > > Enters out_of_memory().
> > > Get SIGKILL.
> > > Get TIF_MEMDIE.
> > > Leaves out_of_memory().
> > > Releases oom_lock.
> > > Enters do_exit().
> > > Calls __mmput().
> > > Takes oom_lock.
> > > Fails get_page_from_freelist().
> > > Releases some memory.
> > > Sets MMF_OOM_SKIP.
> > > Enters out_of_memory().
> > > Ignores MMF_OOM_SKIP mm once.
> > > Leaves out_of_memory().
> > > Releases oom_lock.
> > > Succeeds get_page_from_freelist().
> >
> > OK, so let's say you have another task just about to jump into
> > out_of_memory and ... end up in the same situation.
>
> Right.
>
> >
> > This race is just
> > unavoidable.
>
> There is no perfect way (always timing dependent). But

I would rather not add a code which _pretends_ it solves something. If
we see the above race a real problem in out there then we should think
about how to fix it. I definitely do not want to add more hack into an
already complicated code base.
--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2017-07-21 17:36    [W:0.054 / U:5.756 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site