[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1241787448.28600.26.camel@penberg-laptop>
Date: Fri, 08 May 2009 15:57:28 +0300
From: Pekka Enberg <penberg@...helsinki.fi>
To: Cyrill Gorcunov <gorcunov@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, cl@...ux.com,
mingo@...e.hu, mel@....ul.ie, linux-kernel@...r.kernel.org,
riel@...hat.com, rientjes@...gle.com, xemul@...nvz.org
Subject: [RFC/PATCH v2] mm: Introduce GFP_PANIC for non-failing allocations
From: Cyrill Gorcunov <gorcunov@...nvz.org>
This patch introduces a GFP_PANIC flag that can be used as an annotation
that a call to kmalloc() or alloc_pages() is expected to never fail.
This is useful in early boot code, for example.
To save one GFP flag bit, use a combination of __GFP_NOFAIL,
__GFP_NOREPEAT, and __GFP_NOMEMALLOC to make sure we always end up in
the "nopage" path of the page allocator if an allocation fails.
Signed-off-by: Cyrill Gorcunov <gorcunov@...nvz.org>
Signed-off-by: Pekka Enberg <penberg@...helsinki.fi>
---
Yes, this is totally untested and needs to be rebased on top of -mm.
include/linux/gfp.h | 1 +
mm/page_alloc.c | 3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 0bbc15f..c7c8a63 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -70,6 +70,7 @@ struct vm_area_struct;
#define GFP_HIGHUSER_MOVABLE (__GFP_WAIT | __GFP_IO | __GFP_FS | \
__GFP_HARDWALL | __GFP_HIGHMEM | \
__GFP_MOVABLE)
+#define GFP_PANIC (__GFP_NOFAIL | __GFP_NORETRY | __GFP_NOMEMALLOC)
#ifdef CONFIG_NUMA
#define GFP_THISNODE (__GFP_THISNODE | __GFP_NOWARN | __GFP_NORETRY)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e2f2699..4b062e5 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1670,6 +1670,9 @@ nopage:
dump_stack();
show_mem();
}
+ if (unlikely(gfp_mask & GFP_PANIC))
+ panic("Out of memory: %s order: %d, gfp_mask:0x%x\n",
+ p->comm, order, gfp_mask);
got_pg:
return page;
}
--
1.5.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists