linux-kernel - Re: upcoming kerneloops.org item: get_page_from

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0906242210520.25779@melkki.cs.Helsinki.FI>
Date:	Wed, 24 Jun 2009 22:12:26 +0300 (EEST)
From:	Pekka J Enberg <penberg@...helsinki.fi>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>, arjan@...radead.org,
	linux-kernel@...r.kernel.org, cl@...ux-foundation.org,
	npiggin@...e.de
Subject: Re: upcoming kerneloops.org item: get_page_from_freelist

Hi Linus,

On Wed, 24 Jun 2009, Pekka Enberg wrote:
> > 
> > That said, I do think we ought to fix SLUB not to use __GFP_FAIL for
> > the higher order allocation regardless of this patch.
 
On Wed, 24 Jun 2009, Linus Torvalds wrote:
> I agree. Within the context of SLUB, it makes absolute sense.
> 
> That's especially true since SLUB already uses __GFP_NORETRY or whatever. 
> 
> The combination of __GFP_NOFAIL | __GFP_NORETRY is just insane. So your 
> patch to remove __GFP_NOFAIL when adding __GFP_NORETRY is absolutely the 
> ObviouslyCorrectThingToDo(tm).
> 
> Please integrate that, and take my patch too if you would (add my sign-off 
> or just do your own version)? Or should I just apply them?

Whatever suits you best. I don't have my laptop with me at home so I can't 
test them or send a pull request. I'm including a compile-tested patch 
here in case you want to go ahead and merge them. If you don't want to do 
that, I'll integrate both of the tomorrow morning and send you a pull 
request.

			Pekka

>From 7c251e5a5e7948626bfbcf406f7c90c60f182abd Mon Sep 17 00:00:00 2001
From: Pekka Enberg <penberg@...helsinki.fi>
Date: Wed, 24 Jun 2009 21:59:51 +0300
Subject: [PATCH] SLUB: Don't pass __GFP_FAIL for the initial allocation

SLUB uses higher order allocations by default but falls back to small
orders under memory pressure. Make sure the GFP mask used in the initial
allocation doesn't include __GFP_NOFAIL.

Signed-off-by: Pekka Enberg <penberg@...helsinki.fi>
---
 mm/slub.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index ce62b77..819f056 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1085,11 +1085,17 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
 {
 	struct page *page;
 	struct kmem_cache_order_objects oo = s->oo;
+	gfp_t alloc_gfp;
 
 	flags |= s->allocflags;
 
-	page = alloc_slab_page(flags | __GFP_NOWARN | __GFP_NORETRY, node,
-									oo);
+	/*
+	 * Let the initial higher-order allocation fail under memory pressure
+	 * so we fall-back to the minimum order allocation.
+	 */
+	alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL;
+
+	page = alloc_slab_page(alloc_gfp, node, oo);
 	if (unlikely(!page)) {
 		oo = s->min;
 		/*
-- 
1.5.6.4

--
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/