From: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
Cc: Vlastimil Babka <vbabka-AlSwsSmVLrQ@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
Mel Gorman
<mgorman-3eNAlZScCAx27rWaFMvyedHuzzzSOjJt@public.gmane.org>,
David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Andrea Arcangeli
<aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Anshuman Khandual
<khandual-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
"Kirill A. Shutemov"
<kirill.shutemov-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update
Date: Thu, 18 May 2017 11:08:47 +0200 [thread overview]
Message-ID: <20170518090846.GD25462@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.20.1705171021570.9487-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
On Wed 17-05-17 10:25:09, Cristopher Lameter wrote:
> On Wed, 17 May 2017, Michal Hocko wrote:
>
> > > If you have screwy things like static mbinds in there then you are
> > > hopelessly lost anyways. You may have moved the process to another set
> > > of nodes but the static bindings may refer to a node no longer
> > > available. Thus the OOM is legitimate.
> >
> > The point is that you do _not_ want such a process to trigger the OOM
> > because it can cause other processes being killed.
>
> Nope. The OOM in a cpuset gets the process doing the alloc killed. Or what
> that changed?
>
> At this point you have messed up royally and nothing is going to rescue
> you anyways. OOM or not does not matter anymore. The app will fail.
Not really. If you can trick the system to _think_ that the intersection
between mempolicy and the cpuset is empty then the OOM killer might
trigger an innocent task rather than the one which tricked it into that
situation.
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Christoph Lameter <cl@linux.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, Li Zefan <lizefan@huawei.com>,
Mel Gorman <mgorman@techsingularity.net>,
David Rientjes <rientjes@google.com>,
Hugh Dickins <hughd@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-api@vger.kernel.org
Subject: Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update
Date: Thu, 18 May 2017 11:08:47 +0200 [thread overview]
Message-ID: <20170518090846.GD25462@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.20.1705171021570.9487@east.gentwo.org>
On Wed 17-05-17 10:25:09, Cristopher Lameter wrote:
> On Wed, 17 May 2017, Michal Hocko wrote:
>
> > > If you have screwy things like static mbinds in there then you are
> > > hopelessly lost anyways. You may have moved the process to another set
> > > of nodes but the static bindings may refer to a node no longer
> > > available. Thus the OOM is legitimate.
> >
> > The point is that you do _not_ want such a process to trigger the OOM
> > because it can cause other processes being killed.
>
> Nope. The OOM in a cpuset gets the process doing the alloc killed. Or what
> that changed?
>
> At this point you have messed up royally and nothing is going to rescue
> you anyways. OOM or not does not matter anymore. The app will fail.
Not really. If you can trick the system to _think_ that the intersection
between mempolicy and the cpuset is empty then the OOM killer might
trigger an innocent task rather than the one which tricked it into that
situation.
--
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: Christoph Lameter <cl@linux.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, Li Zefan <lizefan@huawei.com>,
Mel Gorman <mgorman@techsingularity.net>,
David Rientjes <rientjes@google.com>,
Hugh Dickins <hughd@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-api@vger.kernel.org
Subject: Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update
Date: Thu, 18 May 2017 11:08:47 +0200 [thread overview]
Message-ID: <20170518090846.GD25462@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.20.1705171021570.9487@east.gentwo.org>
On Wed 17-05-17 10:25:09, Cristopher Lameter wrote:
> On Wed, 17 May 2017, Michal Hocko wrote:
>
> > > If you have screwy things like static mbinds in there then you are
> > > hopelessly lost anyways. You may have moved the process to another set
> > > of nodes but the static bindings may refer to a node no longer
> > > available. Thus the OOM is legitimate.
> >
> > The point is that you do _not_ want such a process to trigger the OOM
> > because it can cause other processes being killed.
>
> Nope. The OOM in a cpuset gets the process doing the alloc killed. Or what
> that changed?
>
> At this point you have messed up royally and nothing is going to rescue
> you anyways. OOM or not does not matter anymore. The app will fail.
Not really. If you can trick the system to _think_ that the intersection
between mempolicy and the cpuset is empty then the OOM killer might
trigger an innocent task rather than the one which tricked it into that
situation.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2017-05-18 9:08 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-11 14:06 [RFC 0/6] cpuset/mempolicies related fixes and cleanups Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-11 17:24 ` Christoph Lameter
2017-04-11 17:24 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1704111152170.25069-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-04-11 19:00 ` Vlastimil Babka
2017-04-11 19:00 ` Vlastimil Babka
2017-04-11 19:00 ` Vlastimil Babka
2017-04-12 21:25 ` Christoph Lameter
2017-04-12 21:25 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1704121617040.28335-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-04-13 6:24 ` Vlastimil Babka
2017-04-13 6:24 ` Vlastimil Babka
2017-04-13 6:24 ` Vlastimil Babka
2017-04-14 20:37 ` Christoph Lameter
2017-04-14 20:37 ` Christoph Lameter
2017-04-26 8:07 ` Vlastimil Babka
2017-04-26 8:07 ` Vlastimil Babka
2017-04-30 21:33 ` Christoph Lameter
2017-04-30 21:33 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1704301628460.21533-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-05-17 9:20 ` Michal Hocko
2017-05-17 9:20 ` Michal Hocko
2017-05-17 9:20 ` Michal Hocko
[not found] ` <20170517092042.GH18247-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-17 13:56 ` Christoph Lameter
2017-05-17 13:56 ` Christoph Lameter
2017-05-17 13:56 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1705170855430.7925-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-05-17 14:05 ` Michal Hocko
2017-05-17 14:05 ` Michal Hocko
2017-05-17 14:05 ` Michal Hocko
2017-05-17 14:48 ` Christoph Lameter
2017-05-17 14:48 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1705170943090.8714-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-05-17 14:56 ` Michal Hocko
2017-05-17 14:56 ` Michal Hocko
2017-05-17 14:56 ` Michal Hocko
2017-05-17 15:25 ` Christoph Lameter
2017-05-17 15:25 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1705171021570.9487-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-05-18 9:08 ` Michal Hocko [this message]
2017-05-18 9:08 ` Michal Hocko
2017-05-18 9:08 ` Michal Hocko
[not found] ` <20170518090846.GD25462-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-18 16:57 ` Christoph Lameter
2017-05-18 16:57 ` Christoph Lameter
2017-05-18 16:57 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1705181154450.27641-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-05-18 17:24 ` Michal Hocko
2017-05-18 17:24 ` Michal Hocko
2017-05-18 17:24 ` Michal Hocko
[not found] ` <20170518172424.GB30148-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-18 19:07 ` Christoph Lameter
2017-05-18 19:07 ` Christoph Lameter
2017-05-18 19:07 ` Christoph Lameter
2017-05-19 7:37 ` Michal Hocko
2017-05-19 7:37 ` Michal Hocko
2017-05-17 15:27 ` Christoph Lameter
2017-05-17 15:27 ` Christoph Lameter
2017-05-18 10:03 ` Vlastimil Babka
2017-05-18 10:03 ` Vlastimil Babka
2017-05-18 17:07 ` Christoph Lameter
2017-05-18 17:07 ` Christoph Lameter
2017-05-19 11:27 ` Vlastimil Babka
2017-05-19 11:27 ` Vlastimil Babka
2017-04-13 5:42 ` Anshuman Khandual
2017-04-13 5:42 ` Anshuman Khandual
2017-04-13 6:06 ` Vlastimil Babka
2017-04-13 6:06 ` Vlastimil Babka
2017-04-13 6:07 ` Vlastimil Babka
2017-04-13 6:07 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 2/6] mm, mempolicy: stop adjusting current->il_next in mpol_rebind_nodemask() Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-11 17:32 ` Christoph Lameter
2017-04-11 17:32 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1704111227080.25069-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-04-11 19:03 ` Vlastimil Babka
2017-04-11 19:03 ` Vlastimil Babka
2017-04-11 19:03 ` Vlastimil Babka
2017-04-12 8:49 ` Vlastimil Babka
2017-04-12 8:49 ` Vlastimil Babka
[not found] ` <97045760-77eb-c892-9bcb-daad10a1d91d-AlSwsSmVLrQ@public.gmane.org>
2017-04-12 21:16 ` Christoph Lameter
2017-04-12 21:16 ` Christoph Lameter
2017-04-12 21:16 ` Christoph Lameter
2017-04-12 21:18 ` Vlastimil Babka
2017-04-12 21:18 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 3/6] mm, page_alloc: pass preferred nid instead of zonelist to allocator Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 4/6] mm, mempolicy: simplify rebinding mempolicies when updating cpusets Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 5/6] mm, cpuset: always use seqlock when changing task's nodemask Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-12 8:10 ` Hillf Danton
2017-04-12 8:10 ` Hillf Danton
2017-04-12 8:18 ` Vlastimil Babka
2017-04-12 8:18 ` Vlastimil Babka
2017-04-12 8:18 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 6/6] mm, mempolicy: don't check cpuset seqlock where it doesn't matter Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
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=20170518090846.GD25462@dhcp22.suse.cz \
--to=mhocko-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org \
--cc=hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=khandual-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=kirill.shutemov-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=mgorman-3eNAlZScCAx27rWaFMvyedHuzzzSOjJt@public.gmane.org \
--cc=rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=vbabka-AlSwsSmVLrQ@public.gmane.org \
/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.