public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: David Rientjes <rientjes@google.com>
Cc: gregkh@suse.de, npiggin@suse.de, mel@csn.ul.ie,
	a.p.zijlstra@chello.nl, cl@linux-foundation.org,
	dave@linux.vnet.ibm.com, san@android.com, arve@android.com,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 08/11 -mmotm] oom: invoke oom killer for __GFP_NOFAIL
Date: Mon, 11 May 2009 15:11:30 -0700	[thread overview]
Message-ID: <20090511151130.9a949cb7.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.2.00.0905111444070.466@chino.kir.corp.google.com>

On Mon, 11 May 2009 14:45:18 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:

> On Mon, 11 May 2009, Andrew Morton wrote:
> 
> > > The oom killer must be invoked regardless of the order if the allocation
> > > is __GFP_NOFAIL, otherwise it will loop forever when reclaim fails to
> > > free some memory.
> > 
> > We should discourage callers from using __GFP_NOFAIL at all.  We should
> > electrocute callers for using __GFP_NOFAIL on large allocations.  How's about
> > 
> > 	WARN_ON_ONCE(order > PAGE_ALLOC_COSTLY_ORDER &&	
> > 			(gfp_mask & __GFP_NOFAIL));
> > or, preferably:
> > 
> > 	WARN_ON_ONCE(order > 0 && (gfp_mask & __GFP_NOFAIL));
> > 
> 
> Not sure it would help since the oom killer will be now be called for such 
> an allocation and that dumps the stack (and will actually show the order 
> and gfp flags as well).

No, the intent of that warning is to find all call sites which use
__GFP_NOFAIL on order>0 so we can hunt down and eliminate them.


please review...

From: Andrew Morton <akpm@linux-foundation.org>

__GFP_NOFAIL is a bad fiction.  Allocations _can_ fail, and callers should
detect and suitably handle this (and not by lamely moving the infinite
loop up to the caller level either).

Attempting to use __GFP_NOFAIL for a higher-order allocation is even
worse, so add a once-off runtime check for this to slap people around for
even thinking about trying it.

Cc: David Rientjes <rientjes@google.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/page_alloc.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff -puN mm/page_alloc.c~a mm/page_alloc.c
--- a/mm/page_alloc.c~a
+++ a/mm/page_alloc.c
@@ -1201,8 +1201,19 @@ static int should_fail_alloc_page(gfp_t 
 {
 	if (order < fail_page_alloc.min_order)
 		return 0;
-	if (gfp_mask & __GFP_NOFAIL)
+	if (gfp_mask & __GFP_NOFAIL) {
+		/*
+		 * __GFP_NOFAIL is not to be used in new code.
+		 *
+		 * All __GFP_NOFAIL callers should be fixed so that they
+		 * properly detect and handle allocation failures.
+		 *
+		 * We most definitely don't want callers attempting to allocate
+		 * greater than single-page units with __GFP_NOFAIL.
+		 */
+		WARN_ON_ONCE(order > 0);
 		return 0;
+	}
 	if (fail_page_alloc.ignore_gfp_highmem && (gfp_mask & __GFP_HIGHMEM))
 		return 0;
 	if (fail_page_alloc.ignore_gfp_wait && (gfp_mask & __GFP_WAIT))
_



  reply	other threads:[~2009-05-11 22:17 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-10 22:07 [patch 01/11 -mmotm] lowmemorykiller: Only iterate over process list when needed David Rientjes
2009-05-10 22:07 ` [patch 02/11 -mmotm] lowmemorykiller: Don't count free space unless it meets the specified limit by itself David Rientjes
2009-05-12  9:23   ` Mel Gorman
2009-05-13  0:27     ` Arve Hjønnevåg
2009-05-13  9:42       ` Mel Gorman
2009-05-14 23:25         ` Arve Hjønnevåg
2009-05-15  9:18           ` Mel Gorman
2009-05-10 22:07 ` [patch 03/11 -mmotm] oom: cleanup android low memory killer David Rientjes
2009-05-10 22:07 ` [patch 04/11 -mmotm] oom: fix possible android low memory killer NULL pointer David Rientjes
2009-05-10 22:07 ` [patch 05/11 -mmotm] oom: fix possible oom_dump_tasks " David Rientjes
2009-05-11 21:11   ` Andrew Morton
2009-05-11 21:28     ` David Rientjes
2009-05-11 21:41       ` Greg KH
2009-05-11 22:05         ` David Rientjes
2009-05-12  9:38   ` Mel Gorman
2009-05-10 22:07 ` [patch 06/11 -mmotm] oom: move oom_adj value from task_struct to mm_struct David Rientjes
2009-05-11  0:17   ` KOSAKI Motohiro
2009-05-11  0:26     ` David Rientjes
2009-05-11  1:47       ` KOSAKI Motohiro
2009-05-11  8:43         ` David Rientjes
2009-05-11 21:19           ` Andrew Morton
2009-05-12  9:56   ` Mel Gorman
2009-05-10 22:07 ` [patch 07/11 -mmotm] oom: prevent possible OOM_DISABLE livelock David Rientjes
2009-05-11 21:22   ` Andrew Morton
2009-05-10 22:07 ` [patch 08/11 -mmotm] oom: invoke oom killer for __GFP_NOFAIL David Rientjes
2009-05-10 23:59   ` KOSAKI Motohiro
2009-05-11  0:24     ` David Rientjes
2009-05-11  1:45       ` KOSAKI Motohiro
2009-05-11  7:40         ` Minchan Kim
2009-05-11  8:49           ` David Rientjes
2009-05-11 11:23             ` Minchan Kim
2009-05-11  8:45         ` David Rientjes
2009-05-11 16:03           ` Dave Hansen
2009-05-11 19:09             ` David Rientjes
2009-05-11 19:45               ` Dave Hansen
2009-05-11 20:21                 ` David Rientjes
2009-05-11 21:29   ` Andrew Morton
2009-05-11 21:45     ` David Rientjes
2009-05-11 22:11       ` Andrew Morton [this message]
2009-05-11 22:31         ` David Rientjes
2009-05-11 22:46           ` Andrew Morton
2009-05-11 23:00             ` David Rientjes
2009-05-11 23:14               ` Andrew Morton
2009-05-11 23:37                 ` David Rientjes
2009-05-12  5:39         ` Peter Zijlstra
2009-05-12 11:36           ` KOSAKI Motohiro
2009-05-12 10:05         ` Mel Gorman
2009-05-10 22:07 ` [patch 09/11 -mmotm] oom: return vm size of oom killed task David Rientjes
2009-05-11 21:36   ` Andrew Morton
2009-05-10 22:07 ` [patch 10/11 -mmotm] oom: avoid oom kill if no interruptible tasks David Rientjes
2009-05-11 21:39   ` Andrew Morton
2009-05-11 23:08     ` David Rientjes
2009-05-10 22:07 ` [patch 11/11 -mmotm] oom: fail allocations if oom killer can't free memory David Rientjes
2009-05-12 21:14   ` Misleading OOM messages Christoph Lameter
2009-05-14  9:29     ` Pavel Machek
2009-05-14 19:46       ` Christoph Lameter
2009-05-14 20:38         ` Dave Hansen
2009-05-14 20:49           ` Christoph Lameter
2009-05-14 20:49           ` David Rientjes
2009-05-14 21:05             ` Dave Hansen
2009-05-14 21:12               ` David Rientjes
2009-05-14 21:30               ` Christoph Lameter
2009-05-14 21:34                 ` Pavel Machek
2009-05-14 21:41                   ` Dave Hansen
2009-05-15 13:05                     ` Pavel Machek
2009-05-15 17:59                       ` Christoph Lameter
2009-05-15 18:22                         ` Dave Hansen
2009-05-15 19:29                           ` Christoph Lameter
2009-05-15 20:02                         ` Pavel Machek
2009-05-15 21:15                           ` Christoph Lameter
2009-05-19 20:39                             ` Pavel Machek
2009-05-22 13:53                               ` Christoph Lameter
2009-05-22 14:17                                 ` Warn when we run out of swap space (was Re: Misleading OOM messages) Christoph Lameter
2009-05-22 14:56                                   ` Pavel Machek
2009-05-22 19:01                               ` Misleading OOM messages Christoph Lameter
2009-05-22 19:40                                 ` Randy Dunlap
2009-05-22 19:44                                   ` Christoph Lameter
2009-05-22 21:45                                     ` Alan Cox
2009-05-22 21:43                                 ` Alan Cox
2009-05-15 17:57                   ` Christoph Lameter
2009-05-15 18:15                     ` Dave Hansen
2009-05-15 18:19                       ` Balbir Singh
2009-05-15 19:26                       ` Christoph Lameter
2009-05-15 20:31                         ` Balbir Singh
2009-05-18 14:34                           ` Christoph Lameter
2009-05-18 15:45                             ` Balbir Singh
2009-05-14 21:37                 ` Dave Hansen
2009-05-14 22:00                   ` David Rientjes
2009-05-15 17:58                     ` Christoph Lameter
2009-05-15 18:23                       ` Dave Hansen
2009-05-15 18:57                         ` Balbir Singh
2009-05-15 19:37                         ` David Rientjes
2009-05-14 20:56         ` Pavel Machek
2009-05-12  9:09 ` [patch 01/11 -mmotm] lowmemorykiller: Only iterate over process list when needed Mel Gorman
2009-05-13  0:43   ` Arve Hjønnevåg

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=20090511151130.9a949cb7.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=arve@android.com \
    --cc=cl@linux-foundation.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=npiggin@suse.de \
    --cc=rientjes@google.com \
    --cc=san@android.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox