On Wed, 27 Nov 2013, Russell King - ARM Linux wrote: > On Wed, Nov 27, 2013 at 01:32:31PM +0000, Russell King - ARM Linux wrote: > > On Wed, Nov 27, 2013 at 02:29:41PM +0100, Thomas Gleixner wrote: > > > Though the kobject is the only thing which has a delayed work embedded > > > inside struct kmem_cache. And the debug object splat points at the > > > kmem_cache_free() of the struct kmem_cache itself. That's why I > > > assumed the wreckage around that place. And indeed: > > > > > > kmem_cache_destroy(s) > > > __kmem_cache_shutdown(s) > > > sysfs_slab_remove(s) > > > .... > > > kobject_put(&s->kobj) > > > kref_put(&kobj->kref, kobject_release); > > > kobject_release(kref) > > > #ifdef CONFIG_DEBUG_KOBJECT_RELEASE > > > schedule_delayed_work(&kobj->release) > > > #else > > > kobject_cleanup(kobj) > > > #endif > > > > > > So in the CONFIG_DEBUG_KOBJECT_RELEASE=y case, schedule_delayed_work() > > > _IS_ called which arms the timer. debugobjects catches the attempt to > > > free struct kmem_cache which contains the armed timer. > > > > You fail to show where the free is in the above path. > > Right, there's a kmem_cache_free(kmem_cache, s); by the slob code > after the above sequence, which is The Bug(tm). > > As I said, a kobject has its own lifetime. If you embed that into > another structure, that structure inherits the lifetime of the kobject, > which is from the point at which it's created to the point at which the > kobject's release function is called. > > So no, the code here is buggy. The kobject debugging has yet again > found a violation of the kobject lifetime rules. slub needs fixing. I leave that discussion to you, greg and the slub folks. /me prepares deck chair, drinks and popcorn -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
