netdev - Re: ipw2200: firmware DMA loading rework

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: <20090905142837.GI16217@mit.edu>
Date:	Sat, 5 Sep 2009 10:28:37 -0400
From:	Theodore Tso <tytso@....edu>
To:	Mel Gorman <mel@....ul.ie>
Cc:	"Luis R. Rodriguez" <mcgrof@...il.com>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Zhu Yi <yi.zhu@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Mel Gorman <mel@...net.ie>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	James Ketrenos <jketreno@...ux.intel.com>,
	"Chatre, Reinette" <reinette.chatre@...el.com>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"ipw2100-devel@...ts.sourceforge.net" 
	<ipw2100-devel@...ts.sourceforge.net>
Subject: Re: ipw2200: firmware DMA loading rework

On Thu, Sep 03, 2009 at 01:49:14PM +0100, Mel Gorman wrote:
> > 
> > This looks very similar to the kmemleak ext4 reports upon a mount. If
> > it is the same issue, which from the trace it seems it is, then this
> > is due to an extra kmalloc() allocation and this apparently will not
> > get fixed on 2.6.31 due to the closeness of the merge window and the
> > non-criticalness this issue has been deemed.

No, it's a different problem.

> I suspect the more pressing concern is why is this kmalloc() resulting in
> an order-5 allocation request? What size is the buffer being requested?
> Was that expected?  What is the contents of /proc/slabinfo in case a buffer
> that should have required order-1 or order-2 is using a higher order for
> some reason.

It's allocating 68,000 bytes for the mb_history structure, which is
used for debugging purposes.  That's why it's optional and we continue
if it's not allocated.  We should fix it to use vmalloc() and I'm
inclined to turn it off by default since it's not worth the overhead,
and most ext4 users won't find it useful or interesting.

	      	   	      	    	 - Ted
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html