On Sun, 2009-02-15 at 13:36 -0800, Andrew Morton wrote: > On Thu, 12 Feb 2009 17:55:04 +0200 Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote: > > > On Thu, Feb 12, 2009 at 12:45:21PM +0200, Pekka Enberg wrote: > > > > > > > > Because the API was being widely abused in the nommu code, for example. > > > > I'd rather not add it back for this special case which can be handled > > > > otherwise. > > > > On Thu, 2009-02-12 at 18:50 +0800, Herbert Xu wrote: > > > I'm sorry but that's like banning the use of heaters just because > > > they can abused and cause fires. > > > > > > I think I've said this to you before but in networking we very much > > > want to use ksize because the standard case of a 1500-byte packet > > > has loads of extra room given by kmalloc which all goes to waste > > > right now. > > > > > > If we could use ksize then we can stuff loads of metadata in that > > > space. > > > > OK, fair enough, I applied Kirill's patch. Thanks. > > > > Could we please have more details regarding this: > > > The ksize() function is not exported to modules because it has non-standard > > behavour across different slab allocators. > > How does the behaviour differ? It this documented? Can we fix it? SLAB and SLUB support calling ksize() on objects returned by kmem_cache_alloc. SLOB only supports it on objects from kmalloc. This is because it does not store any size or type information in kmem_cache_alloc'ed objects. Instead, it infers them from the cache argument. Ideally SLAB and SLUB would complain about using ksize inappropriately when debugging was enabled. -- http://selenic.com : development and support for Mercurial and Linux -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
