On Wed, 25 Jan 2012 15:05:03 +0100 (CET) Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > On Tue, 24 Jan 2012, Jeff Layton wrote: > > > Still, I wonder if there are other problems like this around. The slab > > > allocators seem to call debug_check_no_obj_freed() on kmem_cache_free, > > > but parts of the objects themselves (like the timer in the work object > > > here) get initialized in other places and aren't necessarily > > > reinitialized when they're recycled out of the slab... > > > > > > > On second thought...getting rid of the ctor function here might be > > problematic. We have to call inode_init_once, etc... > > > > Almost all of the inode slabs have one, so I've settled for just moving > > the INIT_DELAYED_WORK call out of init_once and into rpc_alloc_inode. I > > sent a patch to Trond and linux-nfs to do that. That will fix this > > case, but I do wonder if there are other places in the kernel that have > > similar problems with debugobject initialization. > > The problem is that debugobject requires that a newly allocated object > is reinitialized and made available to the debugobjects code again > simply because we remove it from the debugobjects core on > kmem_cache_free(). > > The real question is why the heck kmem_cache_alloc() does not call the > ctor on each allocation and just expects the previously used and freed > object to be in a consistent initialiazed state. > > Thanks, > > tglx I believe that's by design. The comments at the top of slab.c say: * This means, that your constructor is used only for newly allocated * slabs and you must pass objects with the same initializations to * kmem_cache_free. I assume that it was done that way for efficiency, but not passing "clean" objects to kmem_cache_free has been the source of bugs in the past. Rerunning the ctor should be safe. SLAB already does that when memory poisoning is enabled. Perhaps we could make sure all the allocators do that when debug objects are enabled? OTOH, doing that might paper over bugs in some cases... -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
