linux-kernel - Re: [PATCH] slab: deal with NULL pointers passed to kmem_cache

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.0703211531450.16596@sbz-30.cs.Helsinki.FI>
Date:	Wed, 21 Mar 2007 15:36:34 +0200 (EET)
From:	Pekka J Enberg <penberg@...helsinki.fi>
To:	Jarek Poplawski <jarkao2@...pl>
cc:	Eric Dumazet <dada1@...mosbay.com>,
	Andrew Morton <akpm@...ux-foundation.org>, mpm@...enic.com,
	Christoph Lameter <clameter@....com>,
	"ast\\@domdv\\.de" <ast@...dv.de>,
	"linux-kernel\\@vger\\.kernel\\.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] slab: deal with NULL pointers passed to kmem_cache_free

On Wed, 21 Mar 2007, Jarek Poplawski wrote:
> With  __kmem_cache_free you would set #1 I hope, but if
> nobody would use this - debugging time wouldn't change.

I think you got it backwards. I suggested making the _current_ 
kmem_cache_free() deal with NULL (so everyone will get it) and add a new 
optimized __kmem_cache_free() for those call-sites that really need it.

On Wed, 21 Mar 2007, Jarek Poplawski wrote:
> This could be acceptable, if there were no problems
> with fixing the errors. But there are problems - bugs
> like this aren't fixed on time - maybe because people
> waste too much time per bug?

You're barking up the wrong tree here, Jarek. I strongly feel that we 
should be more defensive in the slab for the exact reasons you outlined. 
There's bunch of bug reports people seem to dismiss as slab errors where 
in fact it's caused by a buggy caller.

That said, Eric and Andrew make a good point about kmem_cache_free() being 
in super-hot paths which clearly must be addressed. The only reason 
holding me back is the fact that I don't know what those super-hot 
call-sites are (with the exception of network skb allocation) so I am 
really in no position to make that patch.

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