On Wed, Nov 27, 2013 at 11:45:17AM +0100, Thomas Gleixner wrote: > On Wed, 27 Nov 2013, Pablo Neira Ayuso wrote: > > > On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote: > > > Ping? I still see this warning. > > > > Did your test include patch 0c3c6c00c6? > > And how is that patch supposed to help? > > > > >[ 418.312449] WARNING: CPU: 6 PID: 4178 at lib/debugobjects.c:260 debug_print_object+0x8d/0xb0() > > > >[ 418.313243] ODEBUG: free active (active state 0) object type: timer_list hint: > > > >delayed_work_timer_fn+0x0/0x20 > > > > >[ 418.321101] [<ffffffff812874d7>] kmem_cache_free+0x197/0x340 > > > >[ 418.321101] [<ffffffff81249e76>] kmem_cache_destroy+0x86/0xe0 > > > >[ 418.321101] [<ffffffff83d5d681>] nf_conntrack_cleanup_net_list+0x131/0x170 > > The debug code detects an active timer, which itself is part of a > delayed work struct. The call comes from kmem_cache_destroy(). > > kmem_cache_free(kmem_cache, s); > > So debug object says: s contains an active timer. s is the kmem_cache > which is destroyed from nf_conntrack_cleanup_net_list. > > Now struct kmem_cache has in case of SLUB: > > struct kobject kobj; /* For sysfs */ > > and struct kobject has: > > #ifdef CONFIG_DEBUG_KOBJECT_RELEASE > struct delayed_work release; > #endif > > So this is the thing you want to look at: > > commit c817a67ec (kobject: delayed kobject release: help find buggy > drivers) added that delayed work thing. > > I fear that does not work for kobjects which are embedded into > something else. No, kobjects embedded into something else have their lifetime determined by the embedded kobject. That's rule #1 of kobjects - or rather reference counted objects. The point at which the kobject gets destructed is when the release function is called. If it is destructed before that time, that's a violation of the reference counted nature of kobjects, and that's what the delay on releasing is designed to catch. It's designed to catch code which does this exact path: put(obj) free(obj) rather than code which does it the right way: put(obj) -> refcount becomes 0 -> release function gets called ->free(obj) The former is unsafe because obj may have other references. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>