From: Thomas Gleixner <tglx@linutronix.de>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
Sasha Levin <sasha.levin@oracle.com>,
Patrick McHardy <kaber@trash.net>,
kadlec@blackhole.kfki.hu, "David S. Miller" <davem@davemloft.net>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
netdev@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux-foundation.org>,
Greg KH <greg@kroah.com>
Subject: Re: netfilter: active obj WARN when cleaning up
Date: Wed, 27 Nov 2013 14:29:41 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.02.1311271409280.30673@ionos.tec.linutronix.de> (raw)
In-Reply-To: <20131127113939.GL16735@n2100.arm.linux.org.uk>
On Wed, 27 Nov 2013, Russell King - ARM Linux wrote:
> 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.
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
next prev parent reply other threads:[~2013-11-27 13:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-07 13:10 netfilter: active obj WARN when cleaning up Sasha Levin
2013-11-26 19:11 ` Sasha Levin
2013-11-26 23:07 ` Pablo Neira Ayuso
2013-11-26 23:13 ` Sasha Levin
2013-11-27 10:45 ` Thomas Gleixner
2013-11-27 11:39 ` Russell King - ARM Linux
2013-11-27 13:29 ` Thomas Gleixner [this message]
2013-11-27 13:32 ` Russell King - ARM Linux
2013-11-27 13:40 ` Russell King - ARM Linux
2013-11-27 13:44 ` Thomas Gleixner
2013-11-27 23:34 ` Greg KH
2013-12-02 16:33 ` Christoph Lameter
2013-12-02 16:40 ` Greg KH
2013-12-02 17:18 ` Christoph Lameter
2013-12-02 17:26 ` Greg KH
2013-12-02 19:00 ` Christoph Lameter
2013-12-02 19:08 ` Greg KH
2013-12-02 19:41 ` Christoph Lameter
2013-12-02 21:22 ` Greg KH
2013-12-02 21:55 ` Christoph Lameter
2013-12-02 22:22 ` Greg KH
2013-12-03 15:22 ` Christoph Lameter
2013-12-17 19:53 ` Sasha Levin
2013-12-17 20:37 ` Christoph Lameter
2013-12-17 22:09 ` Sasha Levin
2013-12-17 22:01 ` Thomas Gleixner
2013-12-19 12:12 ` Bart Van Assche
2013-12-19 14:20 ` Bart Van Assche
2013-11-27 13:41 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1311271409280.30673@ionos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=greg@kroah.com \
--cc=kaber@trash.net \
--cc=kadlec@blackhole.kfki.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=sasha.levin@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).