All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
	"Patrick McHardy" <kaber@trash.net>,
	"Jozsef Kadlecsik" <kadlec@blackhole.kfki.hu>,
	"David Miller" <davem@davemloft.net>,
	"Knut Petersen" <Knut_Petersen@t-online.de>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Paul McKenney" <paulmck@linux.vnet.ibm.com>,
	"Frédéric Weisbecker" <fweisbec@gmail.com>,
	"Greg KH" <greg@kroah.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"Network Development" <netdev@vger.kernel.org>,
	netfilter-devel@vger.kernel.org
Subject: Re: [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown
Date: Wed, 30 Oct 2013 19:04:47 +0100	[thread overview]
Message-ID: <20131030180447.GA9515@localhost> (raw)
In-Reply-To: <CA+55aFxuVpDo3LvmG9j-Hu7sENLTcsB6_CY2TA4mE-k+CuTeGg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

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.

[-- Attachment #2: linus.patch --]
[-- Type: text/x-diff, Size: 528 bytes --]

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);
 

      parent reply	other threads:[~2013-10-30 18:04 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <525BD08C.2080101@t-online.de>
2013-10-14 17:53 ` [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown Linus Torvalds
2013-10-14 21:28   ` Paul E. McKenney
2013-10-14 21:51     ` Frederic Weisbecker
2013-10-14 22:31       ` Knut Petersen
2013-10-14 22:43         ` Frederic Weisbecker
2013-10-15  6:40       ` Ingo Molnar
2013-10-15  7:53         ` Knut Petersen
2013-10-17 14:25         ` Frederic Weisbecker
2013-10-18  6:30           ` Ingo Molnar
2013-10-14 21:52     ` Knut Petersen
2013-10-14 23:16       ` Paul E. McKenney
2013-10-15  0:59         ` Paul E. McKenney
2013-10-15  8:06           ` Knut Petersen
2013-10-25  8:38   ` Linus Torvalds
2013-10-25  9:02     ` Linus Torvalds
2013-10-25  9:08       ` Paul E. McKenney
2013-10-25  9:17         ` Greg Kroah-Hartman
2013-10-25  9:13       ` Greg Kroah-Hartman
2013-10-25  9:28       ` Rafael J. Wysocki
2013-10-25  9:28         ` Rafael J. Wysocki
2013-10-25  9:51         ` Rafael J. Wysocki
2013-10-25  9:54           ` Viresh Kumar
2013-10-25 10:10           ` Rafael J. Wysocki
2013-10-25 10:00             ` Viresh Kumar
2013-10-25 10:07             ` Linus Torvalds
2013-10-25 11:10               ` Rafael J. Wysocki
2013-10-25 13:49                 ` Viresh Kumar
2013-10-25 14:21                   ` Rafael J. Wysocki
2013-10-28 15:02       ` Knut Petersen
2013-10-25 10:23     ` Thomas Gleixner
2013-10-25 10:48       ` Linus Torvalds
2013-10-26 11:43         ` Ingo Molnar
2013-10-28 14:50           ` Knut Petersen
2013-10-28 15:01             ` Ingo Molnar
2013-10-28 15:16               ` Ingo Molnar
2013-10-28 15:45                 ` Knut Petersen
2013-10-27 20:20         ` Linus Torvalds
2013-10-27 20:39           ` Linus Torvalds
2013-10-27 21:13             ` Linus Torvalds
2013-10-27 21:24               ` Greg Kroah-Hartman
2013-10-28 17:23                 ` Bjorn Helgaas
2013-10-28 17:30                   ` Veaceslav Falico
2013-10-28 17:35                     ` Bjorn Helgaas
2013-10-28 17:39                       ` Veaceslav Falico
2013-10-28 18:52                   ` Greg Kroah-Hartman
2013-10-30 18:04             ` Pablo Neira Ayuso [this message]

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=20131030180447.GA9515@localhost \
    --to=pablo@netfilter.org \
    --cc=Knut_Petersen@t-online.de \
    --cc=davem@davemloft.net \
    --cc=fweisbec@gmail.com \
    --cc=greg@kroah.com \
    --cc=kaber@trash.net \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.