linux-kernel - Re: [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]

Date:	Thu, 22 Oct 2009 11:20:14 +0100
From:	Mel Gorman <mel@....ul.ie>
To:	Karol Lewandowski <karol.k.lewandowski@...il.com>
Cc:	David Rientjes <rientjes@...gle.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Frans Pop <elendil@...net.nl>,
	Pekka Enberg <penberg@...helsinki.fi>,
	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: Re: [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 Wed, Oct 21, 2009 at 11:20:34PM +0200, Karol Lewandowski wrote:
> On Wed, Oct 21, 2009 at 02:06:41PM -0700, David Rientjes wrote:
> > On Wed, 21 Oct 2009, Karol Lewandowski wrote:
> > 
> > > 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.
> > >     
> > 
> > No, it clears __GFP_NOFAIL from the first allocation of oo_order(s->oo).  
> > If that fails (and it's easy to fail, it has __GFP_NORETRY), another 
> > allocation is attempted with oo_order(s->min), for which __GFP_NOFAIL 
> > would be preserved if that's the slab cache's allocflags.
> 
> Right, patch is junk.
> 
> However, I haven't been able to trigger failures since I've switched
> to SLAB allocator.  That patch seemed related (and wrong), but it
> wasn't.
> 

Interesting. Pekka, I looked for SLUB commits in the 2.6.30..2.6.31
range for patches that might affect what order of pages SLUB allocates
but didn't spot anything obvious. Can you think of any changes that
might have altered how SLUB uses memory?

> > >  		 */
> > > -		page = alloc_slab_page(flags, node, oo);
> > > +		page = alloc_slab_page(flags | nofail, node, oo);
> > >  		if (!page)
> > >  			return NULL;
> > >  
> > > 
> > 
> > This does nothing.  You may have missed that the lower order allocation is 
> > passing 'flags' (which is a union of the gfp flags passed to 
> > allocate_slab() based on the allocation context and the cache's 
> > allocflags), and not alloc_gfp where __GFP_NOFAIL is masked.
> 
> Right, I missed that.
> 
> > Nack.
> > 
> > Note: slub isn't going to be a culprit in order 5 allocation failures 
> > since they have kmalloc passthrough to the page allocator.
> 
> However, it might change fragmentation somewhat I guess.  This might
> make problem more/less visible.
> 

Did you have CONFIG_KMEMCHECK set by any chance?

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/