linux-kernel - Re: [Bug #13319] Page allocation failures with b43 and p54usb

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:	Mon, 8 Jun 2009 15:12:13 +0100
From:	Mel Gorman <mel@....ul.ie>
To:	Pekka J Enberg <penberg@...helsinki.fi>
Cc:	Rik van Riel <riel@...hat.com>,
	Larry Finger <Larry.Finger@...inger.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Johannes Berg <johannes@...solutions.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: [Bug #13319] Page allocation failures with b43 and p54usb

On Mon, Jun 08, 2009 at 04:58:10PM +0300, Pekka J Enberg wrote:
> Hi Mel,
> 
> On Mon, 8 Jun 2009, Mel Gorman wrote:
> > Is there any chance you could hatchet together a patch
> > slab-allocation-failure that reports on slab allocation failures similar
> > to what the page allocator does? Minimally, it should tell us what
> > the size of the allocation was but any other information such as the
> > same of the slab, the size of pages it normally uses are, etc. would
> > also be useful.
> 
> Would something like this be sufficient? Figuring out the actual _size_ 
> passed to kmalloc() is pretty difficult as then we would need to do the 
> NULL test in fastpath code or pass the argument deeper in the call-chain.
> 

It's much better than nothing. In the event of an allocation failure, we'll
know which kmalloc bucket it's coming out of so we'll have a limited range
of possible buffer sizes.

I have some suggestions on what we're outputting though.

> 			Pekka
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 65ffda5..b5acf18 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1565,6 +1565,8 @@ new_slab:
>  		c->page = new;
>  		goto load_freelist;
>  	}
> +	printk(KERN_WARNING "SLUB: unable to satisfy allocation for cache %s (size=%d, node=%d, gfp=%x)\n",
> +		s->name, s->size, node, gfpflags);

size could be almost anything here for a casual reader. You are
outputting the size of the object plus its metadata so the name should
reflect that. I think it would be better to output objsize= and the
object size without the metadata overhead. What do you think?

In addition, include how many objects there are per-slab and include what
the order is being passed to the page allocator when allocating new slabs.
Would that be enough to determine if fallback-to-smaller orders occured?

>  	return NULL;
>  debug:
>  	if (!alloc_debug_processing(s, c->page, object, addr))
> 

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