All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-mm@kvack.org, hannes@cmpxchg.org, rientjes@google.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] oom_reaper: close race without using oom_lock
Date: Fri, 21 Jul 2017 17:33:53 +0200	[thread overview]
Message-ID: <20170721153353.GG5944@dhcp22.suse.cz> (raw)
In-Reply-To: <201707220018.DAE21384.JQFLVMFHSFtOOO@I-love.SAKURA.ne.jp>

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-mm@kvack.org, hannes@cmpxchg.org, rientjes@google.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] oom_reaper: close race without using oom_lock
Date: Fri, 21 Jul 2017 17:33:53 +0200	[thread overview]
Message-ID: <20170721153353.GG5944@dhcp22.suse.cz> (raw)
In-Reply-To: <201707220018.DAE21384.JQFLVMFHSFtOOO@I-love.SAKURA.ne.jp>

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

  reply	other threads:[~2017-07-21 15:33 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-18 14:06 [PATCH] oom_reaper: close race without using oom_lock Tetsuo Handa
2017-07-18 14:06 ` Tetsuo Handa
2017-07-18 14:16 ` Michal Hocko
2017-07-18 14:16   ` Michal Hocko
2017-07-18 20:51   ` Tetsuo Handa
2017-07-18 20:51     ` Tetsuo Handa
2017-07-20 14:11     ` Michal Hocko
2017-07-20 14:11       ` Michal Hocko
2017-07-20 21:47       ` Tetsuo Handa
2017-07-20 21:47         ` Tetsuo Handa
2017-07-21 15:00         ` Michal Hocko
2017-07-21 15:00           ` Michal Hocko
2017-07-21 15:18           ` Tetsuo Handa
2017-07-21 15:18             ` Tetsuo Handa
2017-07-21 15:33             ` Michal Hocko [this message]
2017-07-21 15:33               ` Michal Hocko
2017-07-23  0:41               ` Tetsuo Handa
2017-07-23  0:41                 ` Tetsuo Handa
2017-07-23  3:03                 ` Tetsuo Handa
2017-07-23  3:03                   ` Tetsuo Handa
2017-07-24  6:38                 ` Michal Hocko
2017-07-24  6:38                   ` Michal Hocko
2017-07-26 11:33                   ` Tetsuo Handa
2017-07-26 11:33                     ` Tetsuo Handa
2017-07-26 11:46                     ` Michal Hocko
2017-07-26 11:46                       ` Michal Hocko
2017-08-05  1:02                       ` Tetsuo Handa
2017-08-05  1:02                         ` Tetsuo Handa
2017-08-07  6:02                         ` Michal Hocko
2017-08-07  6:02                           ` Michal Hocko
2017-08-08  2:14                           ` penguin-kernel
2017-08-10 11:34                             ` Michal Hocko
2017-08-10 11:34                               ` Michal Hocko
2017-08-10 12:10                               ` Tetsuo Handa
2017-08-10 12:10                                 ` Tetsuo Handa
2017-08-10 12:36                                 ` Michal Hocko
2017-08-10 12:36                                   ` Michal Hocko
2017-08-10 14:28                                   ` Tetsuo Handa
2017-08-10 14:28                                     ` Tetsuo Handa
2017-07-18 14:17 ` Johannes Weiner
2017-07-18 14:17   ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170721153353.GG5944@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.