We were tracking down a strange bug in our code that only appeared on
SMP and not UP, and we thought that CONFIG_DEBUG_SLAB (and the ensuing
FORCED_DEBUG which enables SLAB_POISON and SLAB_REDZONE) was going to
catch problems with slab objects, so we were very very confused when a
test like:
struct foo *obj;
cache = kmem_cache_create("test_cache", sizeof(struct foo))
obj = kmem_cache_alloc(cache, GFP_KERNEL);
kmem_cache_free(cache, obj);
// print out contents of obj
was not poisoning obj, or setting the redzone fields on obj to "free".
The problem appears to be in the SMP version of __kmem_cache_alloc()
and __kmem_cache_free(), where it simply sticks the obj in the per-CPU
list without doing the poison or redzone stuff that is done inside
kmem_cache_free_one_tail().
Granted, there are per-slab caches for performance reasons, but putting
the object poisoning and redzoning inside the per-CPU operations does
not cause any additional overhead when it is not enabled, and also helps
to find SMP bugs, especially race conditions between referencing an
object in one thread and freeing it in another (which are much more
prevelant on SMP systems as well).
I'm working on a patch now, if people are interested in this.
Cheers, Andreas
-- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:32 EST