From: Michal Hocko <mhocko@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Al Viro <viro@zeniv.linux.org.uk>, <linux-mm@kvack.org>,
<linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH 0/3] fix few OOM victim allocation runaways
Date: Wed, 1 Feb 2017 10:27:03 +0100 [thread overview]
Message-ID: <20170201092706.9966-1-mhocko@kernel.org> (raw)
Hi,
these three patches tried to address a simple OOM victim runaways when
the oom victim can deplete the memory reserve completely. Tetsuo was able
to trigger the depletion in the write(2) path and I believe the similar
is possible for the read part. Vmalloc would be a bit harder but still
not impossible.
Unfortunately I do not see a better way around this issue as long as we
give OOM victims access to memory reserves without any limits. I have
tried to limit this access [1] which would help at least to keep some
memory for emergency actions. Anyway, even if we limit the amount of
reserves the OOM victim can consume it is still preferable to back off
before accessible reserves are depleted.
Tetsuo was suggesting introducing __GFP_KILLABLE which would fail the
allocation rather than consuming the reserves. I see two problems with
this approach.
1) in order this flags work as expected all the blocking
operations in the allocator call chain (including the direct
reclaim) would have to be killable and this is really non
trivial to achieve. Especially when we do not have any control
over shrinkers.
2) even if the above could be dealt with we would still have to
find all the places which do allocation in the loop based on
the user request. So it wouldn't be simpler than an explicit
fatal_signal_pending check.
Thoughts?
Michal Hocko (3):
fs: break out of iomap_file_buffered_write on fatal signals
mm, fs: check for fatal signals in do_generic_file_read
vmalloc: back of when the current is killed
fs/dax.c | 5 +++++
fs/iomap.c | 3 +++
mm/filemap.c | 5 +++++
mm/vmalloc.c | 5 +++++
4 files changed, 18 insertions(+)
[1] http://lkml.kernel.org/r/20161004090009.7974-2-mhocko@kernel.org
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Al Viro <viro@zeniv.linux.org.uk>, <linux-mm@kvack.org>,
<linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH 0/3] fix few OOM victim allocation runaways
Date: Wed, 1 Feb 2017 10:27:03 +0100 [thread overview]
Message-ID: <20170201092706.9966-1-mhocko@kernel.org> (raw)
Hi,
these three patches tried to address a simple OOM victim runaways when
the oom victim can deplete the memory reserve completely. Tetsuo was able
to trigger the depletion in the write(2) path and I believe the similar
is possible for the read part. Vmalloc would be a bit harder but still
not impossible.
Unfortunately I do not see a better way around this issue as long as we
give OOM victims access to memory reserves without any limits. I have
tried to limit this access [1] which would help at least to keep some
memory for emergency actions. Anyway, even if we limit the amount of
reserves the OOM victim can consume it is still preferable to back off
before accessible reserves are depleted.
Tetsuo was suggesting introducing __GFP_KILLABLE which would fail the
allocation rather than consuming the reserves. I see two problems with
this approach.
1) in order this flags work as expected all the blocking
operations in the allocator call chain (including the direct
reclaim) would have to be killable and this is really non
trivial to achieve. Especially when we do not have any control
over shrinkers.
2) even if the above could be dealt with we would still have to
find all the places which do allocation in the loop based on
the user request. So it wouldn't be simpler than an explicit
fatal_signal_pending check.
Thoughts?
Michal Hocko (3):
fs: break out of iomap_file_buffered_write on fatal signals
mm, fs: check for fatal signals in do_generic_file_read
vmalloc: back of when the current is killed
fs/dax.c | 5 +++++
fs/iomap.c | 3 +++
mm/filemap.c | 5 +++++
mm/vmalloc.c | 5 +++++
4 files changed, 18 insertions(+)
[1] http://lkml.kernel.org/r/20161004090009.7974-2-mhocko@kernel.org
--
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: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH 0/3] fix few OOM victim allocation runaways
Date: Wed, 1 Feb 2017 10:27:03 +0100 [thread overview]
Message-ID: <20170201092706.9966-1-mhocko@kernel.org> (raw)
Hi,
these three patches tried to address a simple OOM victim runaways when
the oom victim can deplete the memory reserve completely. Tetsuo was able
to trigger the depletion in the write(2) path and I believe the similar
is possible for the read part. Vmalloc would be a bit harder but still
not impossible.
Unfortunately I do not see a better way around this issue as long as we
give OOM victims access to memory reserves without any limits. I have
tried to limit this access [1] which would help at least to keep some
memory for emergency actions. Anyway, even if we limit the amount of
reserves the OOM victim can consume it is still preferable to back off
before accessible reserves are depleted.
Tetsuo was suggesting introducing __GFP_KILLABLE which would fail the
allocation rather than consuming the reserves. I see two problems with
this approach.
1) in order this flags work as expected all the blocking
operations in the allocator call chain (including the direct
reclaim) would have to be killable and this is really non
trivial to achieve. Especially when we do not have any control
over shrinkers.
2) even if the above could be dealt with we would still have to
find all the places which do allocation in the loop based on
the user request. So it wouldn't be simpler than an explicit
fatal_signal_pending check.
Thoughts?
Michal Hocko (3):
fs: break out of iomap_file_buffered_write on fatal signals
mm, fs: check for fatal signals in do_generic_file_read
vmalloc: back of when the current is killed
fs/dax.c | 5 +++++
fs/iomap.c | 3 +++
mm/filemap.c | 5 +++++
mm/vmalloc.c | 5 +++++
4 files changed, 18 insertions(+)
[1] http://lkml.kernel.org/r/20161004090009.7974-2-mhocko@kernel.org
--
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>
next reply other threads:[~2017-02-01 9:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-01 9:27 Michal Hocko [this message]
2017-02-01 9:27 ` [PATCH 0/3] fix few OOM victim allocation runaways Michal Hocko
2017-02-01 9:27 ` Michal Hocko
2017-02-01 9:27 ` [PATCH 1/3] fs: break out of iomap_file_buffered_write on fatal signals Michal Hocko
2017-02-01 9:27 ` Michal Hocko
2017-02-01 9:27 ` Michal Hocko
2017-02-01 9:28 ` Christoph Hellwig
2017-02-01 9:28 ` Christoph Hellwig
2017-02-01 9:27 ` [PATCH 2/3] mm, fs: check for fatal signals in do_generic_file_read Michal Hocko
2017-02-01 9:27 ` Michal Hocko
2017-02-01 9:27 ` Michal Hocko
2017-02-01 9:28 ` Christoph Hellwig
2017-02-01 9:28 ` Christoph Hellwig
2017-02-01 9:27 ` [PATCH 3/3] vmalloc: back of when the current is killed Michal Hocko
2017-02-01 9:27 ` Michal Hocko
2017-02-01 9:27 ` Michal Hocko
2017-02-01 9:28 ` Christoph Hellwig
2017-02-01 9:28 ` Christoph Hellwig
2017-02-01 11:49 ` [PATCH 0/3] fix few OOM victim allocation runaways Tetsuo Handa
2017-02-01 11:49 ` Tetsuo Handa
-- strict thread matches above, loose matches on Subject: below --
2017-02-01 9:26 Michal Hocko
2017-02-01 9:26 ` Michal Hocko
2017-02-01 9:26 ` Michal Hocko
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=20170201092706.9966-1-mhocko@kernel.org \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=viro@zeniv.linux.org.uk \
/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.