linux-kernel - Re: [PATCH] oom_reaper: close race without using oom

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170721153353.GG5944@dhcp22.suse.cz>
Date:   Fri, 21 Jul 2017 17:33:53 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     linux-mm@...ck.org, hannes@...xchg.org, rientjes@...gle.com,
        linux-kernel@...r.kernel.org
Subject: Re: [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