On Wed, 27 Nov 2013, Russell King - ARM Linux wrote:

On Wed, Nov 27, 2013 at 11:45:17AM +0100, Thomas Gleixner wrote:

quoted

On Wed, 27 Nov 2013, Pablo Neira Ayuso wrote:

quoted

On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote:

quoted

Ping? I still see this warning.

Did your test include patch 0c3c6c00c6?

And how is that patch supposed to help?
 

quoted

quoted

quoted

[  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

quoted

quoted

quoted

[  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.

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.

So much for rule #1

Thanks,

	tglx

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>