linux-kernel - [PATCH] SLUB: Don't drop __GFP_NOFAIL completely from allocate_slab() (was: Re: [Bug #14265] ifconfig: page allocation failure. order:5,ode:0x8020 w/ e100)

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: <20091021200442.GA2987@bizet.domek.prywatny>
Date:	Wed, 21 Oct 2009 22:04:42 +0200
From:	Karol Lewandowski <karol.k.lewandowski@...il.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Karol Lewandowski <karol.k.lewandowski@...il.com>,
	Mel Gorman <mel@....ul.ie>, Frans Pop <elendil@...net.nl>,
	Pekka Enberg <penberg@...helsinki.fi>,
	David Rientjes <rientjes@...gle.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Reinette Chatre <reinette.chatre@...el.com>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Mohamed Abbas <mohamed.abbas@...el.com>,
	"John W. Linville" <linville@...driver.com>, linux-mm@...ck.org,
	jens.axboe@...cle.com, Tobias Oetiker <tobi@...iker.ch>
Subject: [PATCH] SLUB: Don't drop __GFP_NOFAIL completely from
	allocate_slab() (was: Re: [Bug #14265] ifconfig: page allocation
	failure. order:5,ode:0x8020 w/ e100)

On Thu, Oct 01, 2009 at 09:56:04PM +0200, Rafael J. Wysocki wrote:
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14265
> Subject		: ifconfig: page allocation failure. order:5, mode:0x8020 w/ e100
> Submitter	: Karol Lewandowski <karol.k.lewandowski@...il.com>
> Date		: 2009-09-15 12:05 (17 days old)
> References	: http://marc.info/?l=linux-kernel&m=125301636509517&w=4

Guys, could anyone check if patch below helps?  I think I've finally
found culprit of all allocation failures (but I might be wrong
too... ;-)

Thanks.


commit d6849591e042bceb66f1b4513a1df6740d2ad762
Author: Karol Lewandowski <karol.k.lewandowski@...il.com>
Date:   Wed Oct 21 21:01:20 2009 +0200

    SLUB: Don't drop __GFP_NOFAIL completely from allocate_slab()
    
    Commit ba52270d18fb17ce2cf176b35419dab1e43fe4a3 unconditionally
    cleared __GFP_NOFAIL flag on all allocations.
    
    Preserve this flag on second attempt to allocate page (with possibly
    decreased order).
    
    This should help with bugs #14265, #14141 and similar.
    
    Signed-off-by: Karol Lewandowski <karol.k.lewandowski@...il.com>

diff --git a/mm/slub.c b/mm/slub.c
index b627675..ac5db65 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1084,7 +1084,7 @@ 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;
+	gfp_t alloc_gfp, nofail;
 
 	flags |= s->allocflags;
 
@@ -1092,6 +1092,7 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
 	 * Let the initial higher-order allocation fail under memory pressure
 	 * so we fall-back to the minimum order allocation.
 	 */
+	nofail = flags & __GFP_NOFAIL;
 	alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL;
 
 	page = alloc_slab_page(alloc_gfp, node, oo);
@@ -1100,8 +1101,10 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
 		/*
 		 * Allocation may have failed due to fragmentation.
 		 * Try a lower order alloc if possible
+		 *
+		 * Preserve __GFP_NOFAIL flag if previous allocation failed.
 		 */
-		page = alloc_slab_page(flags, node, oo);
+		page = alloc_slab_page(flags | nofail, node, oo);
 		if (!page)
 			return NULL;
 
--
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/