LKML Archive on
help / color / mirror / Atom feed
From: Michal Hocko <>
To: Andrew Morton <>
Cc: David Rientjes <>,
	Johannes Weiner <>,
	"\\\"Rafael J. Wysocki\\\"" <>,
	Tetsuo Handa <>,
	<>, LKML <>
Subject: [PATCH] mm, oom: do not fail __GFP_NOFAIL allocation if oom killer is disbaled
Date: Tue, 24 Feb 2015 19:19:24 +0100	[thread overview]
Message-ID: <> (raw)

Tetsuo Handa has pointed out that __GFP_NOFAIL allocations might fail
after OOM killer is disabled if the allocation is performed by a
kernel thread. This behavior was introduced from the very beginning by
7f33d49a2ed5 (mm, PM/Freezer: Disable OOM killer when tasks are frozen).
This means that the basic contract for the allocation request is broken
and the context requesting such an allocation might blow up unexpectedly.

There are basically two ways forward.
1) move oom_killer_disable after kernel threads are frozen. This has a
   risk that the OOM victim wouldn't be able to finish because it would
   depend on an already frozen kernel thread. This would be really
   tricky to debug.
2) do not fail GFP_NOFAIL allocation no matter what and risk a potential
   Freezable kernel threads will loop and fail the suspend. Incidental
   allocations after kernel threads are frozen will at least dump a
   warning - if we are lucky and the serial console is still active of

This patch implements the later option because it is safer. We would see
warnings rather than allocation failures for the kernel threads which
would blow up otherwise and have a higher chances to identify
__GFP_NOFAIL users from deeper pm code.

Signed-off-by: Michal Hocko <>

We haven't seen any bug reports 

 mm/oom_kill.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 642f38cb175a..ea8b443cd871 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -772,6 +772,10 @@ out:
+static DEFINE_RATELIMIT_STATE(oom_disabled_rs,
  * out_of_memory -  tries to invoke OOM killer.
  * @zonelist: zonelist pointer
@@ -792,6 +796,10 @@ bool out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask,
 	if (!oom_killer_disabled) {
 		__out_of_memory(zonelist, gfp_mask, order, nodemask, force_kill);
 		ret = true;
+	} else if (gfp_mask & __GFP_NOFAIL) {
+		if (__ratelimit(&oom_disabled_rs))
+			WARN(1, "Unable to make forward progress for __GFP_NOFAIL because OOM killer is disbaled\n");
+		ret = true;

             reply	other threads:[~2015-02-24 18:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-24 18:19 Michal Hocko [this message]
2015-02-24 18:22 ` Michal Hocko
2015-02-24 19:11 ` Johannes Weiner
2015-02-24 20:23   ` David Rientjes
2015-02-25 14:08     ` [PATCH -v2] " Michal Hocko
2015-02-25 20:41       ` David Rientjes
2015-02-26 17:34         ` Michal Hocko
2015-02-24 22:09   ` [PATCH] " Konstantin Khlebnikov
2015-02-24 22:16     ` Konstantin Khlebnikov
2015-02-25 14:02   ` 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:

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

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] mm, oom: do not fail __GFP_NOFAIL allocation if oom killer is disbaled' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).