On Thu, 19 Jul 2007, Roland Dreier wrote: > > I think the oops below is related -- Michael reports that avoiding > kmalloc(0) in the mlx4_ib driver makes it go away.
Ok, I think I see it: I think the mm/slab.c conversion of kmalloc(0) is totally broken. The problem? It returns ZERO_SIZE_PTR from __find_general_cachep(), not from __kmalloc(). So anythign that uses __find_general_cachep() will get an invalid cachep pointer, which was not the point. We're deprecating SLAB, and a lot of people are already using SLUB, which hid this. Does something like this fix it? Christoph, please go over this and see if there are other cases like that. Linus --- diff --git a/mm/slab.c b/mm/slab.c index 88bc633..4bc4bc0 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -775,8 +775,6 @@ static inline struct kmem_cache *__find_general_cachep(size_t size, */ BUG_ON(malloc_sizes[INDEX_AC].cs_cachep == NULL); #endif - if (!size) - return ZERO_SIZE_PTR; while (size > csizep->cs_size) csizep++; @@ -3684,6 +3682,9 @@ static __always_inline void *__do_kmalloc(size_t size, gfp_t flags, { struct kmem_cache *cachep; + if (!size) + return ZERO_SIZE_PTR; + /* If you want to save a few bytes .text space: replace * __ with kmem_. * Then kmalloc uses the uninlined functions instead of the inline - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/