From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Christoph Lameter <cl@gentwo.org>,
Sasha Levin <sasha.levin@oracle.com>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Jones <davej@redhat.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: slub/debugobjects: lockup when freeing memory
Date: Thu, 19 Jun 2014 15:04:49 -0700 [thread overview]
Message-ID: <20140619220449.GT4904@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1406192331250.5170@nanos>
On Thu, Jun 19, 2014 at 11:32:41PM +0200, Thomas Gleixner wrote:
>
>
> On Thu, 19 Jun 2014, Paul E. McKenney wrote:
>
> > On Thu, Jun 19, 2014 at 10:37:17PM +0200, Thomas Gleixner wrote:
> > > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > > > On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas Gleixner wrote:
> > > > > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > > > > Well, no. Look at the callchain:
> > > > >
> > > > > __call_rcu
> > > > > debug_object_activate
> > > > > rcuhead_fixup_activate
> > > > > debug_object_init
> > > > > kmem_cache_alloc
> > > > >
> > > > > So call rcu activates the object, but the object has no reference in
> > > > > the debug objects code so the fixup code is called which inits the
> > > > > object and allocates a reference ....
> > > >
> > > > OK, got it. And you are right, call_rcu() has done this for a very
> > > > long time, so not sure what changed. But it seems like the right
> > > > approach is to provide a debug-object-free call_rcu_alloc() for use
> > > > by the memory allocators.
> > > >
> > > > Seem reasonable? If so, please see the following patch.
> > >
> > > Not really, you're torpedoing the whole purpose of debugobjects :)
> > >
> > > So, why can't we just init the rcu head when the stuff is created?
> >
> > That would allow me to keep my code unchanged, so I am in favor. ;-)
>
> Almost unchanged. You need to provide a function to do so, i.e. make
> use of
>
> debug_init_rcu_head()
You mean like this?
Thanx, Paul
------------------------------------------------------------------------
rcu: Export debug_init_rcu_head() and and debug_init_rcu_head()
Currently, call_rcu() relies on implicit allocation and initialization
for the debug-objects handling of RCU callbacks. If you hammer the
kernel hard enough with Sasha's modified version of trinity, you can end
up with the sl*b allocators recursing into themselves via this implicit
call_rcu() allocation.
This commit therefore exports the debug_init_rcu_head() and
debug_rcu_head_free() functions, which permits the allocators to allocated
and pre-initialize the debug-objects information, so that there no longer
any need for call_rcu() to do that initialization, which in turn prevents
the recursion into the memory allocators.
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 063a6bf1a2b6..34ae5c376e35 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -358,9 +358,19 @@ void wait_rcu_gp(call_rcu_func_t crf);
* initialization.
*/
#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
+void debug_init_rcu_head(struct rcu_head *head);
+void debug_rcu_head_free(struct rcu_head *head);
void init_rcu_head_on_stack(struct rcu_head *head);
void destroy_rcu_head_on_stack(struct rcu_head *head);
#else /* !CONFIG_DEBUG_OBJECTS_RCU_HEAD */
+static inline void debug_init_rcu_head(struct rcu_head *head)
+{
+}
+
+static inline void debug_rcu_head_free(struct rcu_head *head)
+{
+}
+
static inline void init_rcu_head_on_stack(struct rcu_head *head)
{
}
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index a2aeb4df0f60..a41c81a26506 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -200,12 +200,12 @@ void wait_rcu_gp(call_rcu_func_t crf)
EXPORT_SYMBOL_GPL(wait_rcu_gp);
#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
-static inline void debug_init_rcu_head(struct rcu_head *head)
+void debug_init_rcu_head(struct rcu_head *head)
{
debug_object_init(head, &rcuhead_debug_descr);
}
-static inline void debug_rcu_head_free(struct rcu_head *head)
+void debug_rcu_head_free(struct rcu_head *head)
{
debug_object_free(head, &rcuhead_debug_descr);
}
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Christoph Lameter <cl@gentwo.org>,
Sasha Levin <sasha.levin@oracle.com>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Jones <davej@redhat.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: slub/debugobjects: lockup when freeing memory
Date: Thu, 19 Jun 2014 15:04:49 -0700 [thread overview]
Message-ID: <20140619220449.GT4904@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1406192331250.5170@nanos>
On Thu, Jun 19, 2014 at 11:32:41PM +0200, Thomas Gleixner wrote:
>
>
> On Thu, 19 Jun 2014, Paul E. McKenney wrote:
>
> > On Thu, Jun 19, 2014 at 10:37:17PM +0200, Thomas Gleixner wrote:
> > > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > > > On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas Gleixner wrote:
> > > > > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > > > > Well, no. Look at the callchain:
> > > > >
> > > > > __call_rcu
> > > > > debug_object_activate
> > > > > rcuhead_fixup_activate
> > > > > debug_object_init
> > > > > kmem_cache_alloc
> > > > >
> > > > > So call rcu activates the object, but the object has no reference in
> > > > > the debug objects code so the fixup code is called which inits the
> > > > > object and allocates a reference ....
> > > >
> > > > OK, got it. And you are right, call_rcu() has done this for a very
> > > > long time, so not sure what changed. But it seems like the right
> > > > approach is to provide a debug-object-free call_rcu_alloc() for use
> > > > by the memory allocators.
> > > >
> > > > Seem reasonable? If so, please see the following patch.
> > >
> > > Not really, you're torpedoing the whole purpose of debugobjects :)
> > >
> > > So, why can't we just init the rcu head when the stuff is created?
> >
> > That would allow me to keep my code unchanged, so I am in favor. ;-)
>
> Almost unchanged. You need to provide a function to do so, i.e. make
> use of
>
> debug_init_rcu_head()
You mean like this?
Thanx, Paul
------------------------------------------------------------------------
rcu: Export debug_init_rcu_head() and and debug_init_rcu_head()
Currently, call_rcu() relies on implicit allocation and initialization
for the debug-objects handling of RCU callbacks. If you hammer the
kernel hard enough with Sasha's modified version of trinity, you can end
up with the sl*b allocators recursing into themselves via this implicit
call_rcu() allocation.
This commit therefore exports the debug_init_rcu_head() and
debug_rcu_head_free() functions, which permits the allocators to allocated
and pre-initialize the debug-objects information, so that there no longer
any need for call_rcu() to do that initialization, which in turn prevents
the recursion into the memory allocators.
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 063a6bf1a2b6..34ae5c376e35 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -358,9 +358,19 @@ void wait_rcu_gp(call_rcu_func_t crf);
* initialization.
*/
#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
+void debug_init_rcu_head(struct rcu_head *head);
+void debug_rcu_head_free(struct rcu_head *head);
void init_rcu_head_on_stack(struct rcu_head *head);
void destroy_rcu_head_on_stack(struct rcu_head *head);
#else /* !CONFIG_DEBUG_OBJECTS_RCU_HEAD */
+static inline void debug_init_rcu_head(struct rcu_head *head)
+{
+}
+
+static inline void debug_rcu_head_free(struct rcu_head *head)
+{
+}
+
static inline void init_rcu_head_on_stack(struct rcu_head *head)
{
}
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index a2aeb4df0f60..a41c81a26506 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -200,12 +200,12 @@ void wait_rcu_gp(call_rcu_func_t crf)
EXPORT_SYMBOL_GPL(wait_rcu_gp);
#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
-static inline void debug_init_rcu_head(struct rcu_head *head)
+void debug_init_rcu_head(struct rcu_head *head)
{
debug_object_init(head, &rcuhead_debug_descr);
}
-static inline void debug_rcu_head_free(struct rcu_head *head)
+void debug_rcu_head_free(struct rcu_head *head)
{
debug_object_free(head, &rcuhead_debug_descr);
}
next prev parent reply other threads:[~2014-06-19 22:04 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-19 14:30 slub/debugobjects: lockup when freeing memory Sasha Levin
2014-06-19 14:30 ` Sasha Levin
2014-06-19 15:03 ` Christoph Lameter
2014-06-19 15:03 ` Christoph Lameter
2014-06-19 16:52 ` Paul E. McKenney
2014-06-19 16:52 ` Paul E. McKenney
2014-06-19 19:29 ` Thomas Gleixner
2014-06-19 19:29 ` Thomas Gleixner
2014-06-19 20:19 ` Christoph Lameter
2014-06-19 20:19 ` Christoph Lameter
2014-06-19 20:28 ` Thomas Gleixner
2014-06-19 20:28 ` Thomas Gleixner
2014-06-19 20:36 ` Paul E. McKenney
2014-06-19 20:36 ` Paul E. McKenney
2014-08-18 16:37 ` Paul E. McKenney
2014-08-18 16:37 ` Paul E. McKenney
2014-08-19 3:44 ` Christoph Lameter
2014-08-19 3:44 ` Christoph Lameter
2014-08-19 3:58 ` Paul E. McKenney
2014-08-19 3:58 ` Paul E. McKenney
2014-08-20 2:00 ` Christoph Lameter
2014-08-20 2:00 ` Christoph Lameter
2014-08-20 2:31 ` Paul E. McKenney
2014-08-20 2:31 ` Paul E. McKenney
2014-08-20 6:01 ` Christoph Lameter
2014-08-20 6:01 ` Christoph Lameter
2014-08-20 12:19 ` Paul E. McKenney
2014-08-20 12:19 ` Paul E. McKenney
2014-06-19 20:29 ` Paul E. McKenney
2014-06-19 20:29 ` Paul E. McKenney
2014-06-19 20:32 ` Sasha Levin
2014-06-19 20:32 ` Sasha Levin
2014-06-19 20:39 ` Paul E. McKenney
2014-06-19 20:39 ` Paul E. McKenney
2014-06-19 20:37 ` Thomas Gleixner
2014-06-19 20:37 ` Thomas Gleixner
2014-06-19 20:53 ` Paul E. McKenney
2014-06-19 20:53 ` Paul E. McKenney
2014-06-19 21:32 ` Thomas Gleixner
2014-06-19 21:32 ` Thomas Gleixner
2014-06-19 22:04 ` Paul E. McKenney [this message]
2014-06-19 22:04 ` Paul E. McKenney
2014-06-20 8:17 ` Thomas Gleixner
2014-06-20 8:17 ` Thomas Gleixner
2014-06-20 15:40 ` Paul E. McKenney
2014-06-20 15:40 ` Paul E. McKenney
2014-07-12 18:03 ` Sasha Levin
2014-07-12 18:03 ` Sasha Levin
2014-07-12 19:33 ` Paul E. McKenney
2014-07-12 19:33 ` Paul E. McKenney
2014-06-20 14:30 ` Christoph Lameter
2014-06-20 14:30 ` Christoph Lameter
2014-06-19 20:42 ` Sasha Levin
2014-06-19 20:42 ` Sasha Levin
2014-06-19 20:53 ` Paul E. McKenney
2014-06-19 20:53 ` Paul E. McKenney
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=20140619220449.GT4904@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@kernel.org \
--cc=sasha.levin@oracle.com \
--cc=tglx@linutronix.de \
/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.