Patchwork [BUG,3.12.rc4] Oops: unable to handle kernel paging request during shutdown

login
register
mail settings
Submitter Pablo Neira
Date Oct. 30, 2013, 6:04 p.m.
Message ID <20131030180447.GA9515@localhost>
Download mbox | patch
Permalink /patch/287317/
State Superseded
Headers show

Comments

Pablo Neira - Oct. 30, 2013, 6:04 p.m.
On Sun, Oct 27, 2013 at 08:39:47PM +0000, Linus Torvalds wrote:
> On Sun, Oct 27, 2013 at 8:20 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Appended is a warning I get with DEBUG_TIMER_OBJECTS. Seems to be a
> > device-mapper issue.
> 
> .. and here's another one. This time it looks like nf_conntrack_free()
> is freeing something that has a delayed work in it (again, likely an
> embedded 'struct kobject'). Looks like it is the
> 
>     kmem_cache_destroy(net->ct.nf_conntrack_cachep);
> 
> that triggers this. Which probably means that there are still slab
> entries on that slab cache or something, but I didn't dig any deeper..
> 
> David? Patrick? Pablo? Jozsef? Any ideas? This was immediately preceded by
> 
>   [ 1136.316280] kobject: 'nf_conntrack_ffff8800b74d0000'
> (ffff8801196fac78): kobject_uevent_env
>   [ 1136.316287] kobject: 'nf_conntrack_ffff8800b74d0000'
> (ffff8801196fac78): fill_kobj_path: path =
> '/kernel/slab/nf_conntrack_ffff8800b74d0000'
>   [ 1136.316331] kobject: 'nf_conntrack_ffff8800b74d0000'
> (ffff8801196fac78): kobject_release, parent           (null) (delayed)
> 
> and I think it's that delayed "kobject_release()" that triggers this.
> 
> Notice that kobject_release() can be delayed *without* the magic
> kobject debugging option by simply having a reference count on it from
> some external source. So this particular issue is probably triggered
> by my extra debug options in this case (I'm running with all those
> nasty "try to find bad object freeing" options, and doing module
> unloading etc), but can happen without it (it's just very hard to
> trigger in practice without the debug options).

nf_conntrack_free() is decrementing our object counter (net->ct.count)
before releasing the object. That counter is used in the
nf_conntrack_cleanup_net_list path to check if it's time to
kmem_cache_destroy our cache of conntrack objects. I think we have a
race there that should be easier to trigger (although still hard) with
CONFIG_DEBUG_OBJECTS_FREE as object releases become slowier.

Patch

diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 5d892fe..d60cf16 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -764,9 +764,10 @@  void nf_conntrack_free(struct nf_conn *ct)
 	struct net *net = nf_ct_net(ct);
 
 	nf_ct_ext_destroy(ct);
-	atomic_dec(&net->ct.count);
 	nf_ct_ext_free(ct);
 	kmem_cache_free(net->ct.nf_conntrack_cachep, ct);
+	smp_mb__before_atomic_dec();
+	atomic_dec(&net->ct.count);
 }
 EXPORT_SYMBOL_GPL(nf_conntrack_free);