On Wed, Aug 20, 2014 at 01:01:19AM -0500, Christoph Lameter wrote:
> On Tue, 19 Aug 2014, Paul E. McKenney wrote:
>
> > > We could also remove the #ifdefs if init_rcu_head and destroy_rcu_head
> > > are no ops if CONFIG_DEBUG_RCU_HEAD is not defined.
> >
> > And indeed they are, good point! It
On Tue, 19 Aug 2014, Paul E. McKenney wrote:
> > We could also remove the #ifdefs if init_rcu_head and destroy_rcu_head
> > are no ops if CONFIG_DEBUG_RCU_HEAD is not defined.
>
> And indeed they are, good point! It appears to me that both sets of
> #ifdefs can go away.
Ok then this is a first
On Tue, 19 Aug 2014, Paul E. McKenney wrote:
We could also remove the #ifdefs if init_rcu_head and destroy_rcu_head
are no ops if CONFIG_DEBUG_RCU_HEAD is not defined.
And indeed they are, good point! It appears to me that both sets of
#ifdefs can go away.
Ok then this is a first
On Wed, Aug 20, 2014 at 01:01:19AM -0500, Christoph Lameter wrote:
On Tue, 19 Aug 2014, Paul E. McKenney wrote:
We could also remove the #ifdefs if init_rcu_head and destroy_rcu_head
are no ops if CONFIG_DEBUG_RCU_HEAD is not defined.
And indeed they are, good point! It appears to me
On Tue, Aug 19, 2014 at 09:00:05PM -0500, Christoph Lameter wrote:
> On Mon, 18 Aug 2014, Paul E. McKenney wrote:
>
> > > +#ifdef CONFIG_RCU_DEBUG_XYZ
> >
> > If you make CONFIG_RCU_DEBUG_XYZ instead be CONFIG_DEBUG_OBJECTS_RCU_HEAD,
> > then it will automatically show up when it needs to.
>
>
On Mon, 18 Aug 2014, Paul E. McKenney wrote:
> > +#ifdef CONFIG_RCU_DEBUG_XYZ
>
> If you make CONFIG_RCU_DEBUG_XYZ instead be CONFIG_DEBUG_OBJECTS_RCU_HEAD,
> then it will automatically show up when it needs to.
Ok.
> The rest looks plausible, for whatever that is worth.
We talked in the
On Mon, 18 Aug 2014, Paul E. McKenney wrote:
+#ifdef CONFIG_RCU_DEBUG_XYZ
If you make CONFIG_RCU_DEBUG_XYZ instead be CONFIG_DEBUG_OBJECTS_RCU_HEAD,
then it will automatically show up when it needs to.
Ok.
The rest looks plausible, for whatever that is worth.
We talked in the hallway
On Tue, Aug 19, 2014 at 09:00:05PM -0500, Christoph Lameter wrote:
On Mon, 18 Aug 2014, Paul E. McKenney wrote:
+#ifdef CONFIG_RCU_DEBUG_XYZ
If you make CONFIG_RCU_DEBUG_XYZ instead be CONFIG_DEBUG_OBJECTS_RCU_HEAD,
then it will automatically show up when it needs to.
Ok.
The
On Mon, Aug 18, 2014 at 10:44:34PM -0500, Christoph Lameter wrote:
> On Mon, 18 Aug 2014, Paul E. McKenney wrote:
>
> > > > 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
On Mon, 18 Aug 2014, Paul E. McKenney wrote:
> > > 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
> >
> > So we need to init the object in the page struct
On Thu, Jun 19, 2014 at 03:19:39PM -0500, Christoph Lameter wrote:
> On Thu, 19 Jun 2014, Thomas Gleixner wrote:
>
> > Well, no. Look at the callchain:
> >
> > __call_rcu
> > debug_object_activate
> >rcuhead_fixup_activate
> > debug_object_init
> >
On Thu, Jun 19, 2014 at 03:19:39PM -0500, Christoph Lameter wrote:
On Thu, 19 Jun 2014, Thomas Gleixner wrote:
Well, no. Look at the callchain:
__call_rcu
debug_object_activate
rcuhead_fixup_activate
debug_object_init
kmem_cache_alloc
So call
On Mon, 18 Aug 2014, Paul E. McKenney wrote:
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
So we need to init the object in the page struct before the
On Mon, Aug 18, 2014 at 10:44:34PM -0500, Christoph Lameter wrote:
On Mon, 18 Aug 2014, Paul E. McKenney wrote:
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
On Sat, Jul 12, 2014 at 02:03:57PM -0400, Sasha Levin wrote:
> On 06/20/2014 11:40 AM, Paul E. McKenney wrote:
> > 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
On 06/20/2014 11:40 AM, Paul E. McKenney wrote:
> 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
On 06/20/2014 11:40 AM, Paul E. McKenney wrote:
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
On Sat, Jul 12, 2014 at 02:03:57PM -0400, Sasha Levin wrote:
On 06/20/2014 11:40 AM, Paul E. McKenney wrote:
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
On Fri, Jun 20, 2014 at 10:17:32AM +0200, Thomas Gleixner wrote:
> On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > 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
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> 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
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> 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
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
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,
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
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
On Fri, Jun 20, 2014 at 10:17:32AM +0200, Thomas Gleixner wrote:
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
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
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
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:
> > > >
On Thu, Jun 19, 2014 at 04:42:11PM -0400, Sasha Levin wrote:
> On 06/19/2014 04:29 PM, Paul E. McKenney wrote:
> > rcu: Provide call_rcu_alloc() and call_rcu_sched_alloc() to avoid recursion
> >
> > The sl*b allocators use call_rcu() to manage object lifetimes, but
> > call_rcu() can use
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
> >
On Thu, Jun 19, 2014 at 04:32:38PM -0400, Sasha Levin wrote:
> On 06/19/2014 04:29 PM, 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:
> >> >
> >>> > > On Thu, Jun 19, 2014 at 10:03:04AM -0500,
On 06/19/2014 04:29 PM, Paul E. McKenney wrote:
> rcu: Provide call_rcu_alloc() and call_rcu_sched_alloc() to avoid recursion
>
> The sl*b allocators use call_rcu() to manage object lifetimes, but
> call_rcu() can use debug-objects, which in turn invokes the sl*b
> allocators. These allocators
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
> >
On Thu, Jun 19, 2014 at 03:19:39PM -0500, Christoph Lameter wrote:
> On Thu, 19 Jun 2014, Thomas Gleixner wrote:
>
> > Well, no. Look at the callchain:
> >
> > __call_rcu
> > debug_object_activate
> >rcuhead_fixup_activate
> > debug_object_init
> >
On 06/19/2014 04:29 PM, 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:
>> >
>>> > > On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
> > > On Thu, 19 Jun 2014, Sasha Levin wrote:
On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas Gleixner wrote:
> On Thu, 19 Jun 2014, Paul E. McKenney wrote:
>
> > On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
> > > On Thu, 19 Jun 2014, Sasha Levin wrote:
> > >
> > > > [ 690.770137] ? __this_cpu_preempt_check
On Thu, 19 Jun 2014, Christoph Lameter wrote:
> On Thu, 19 Jun 2014, Thomas Gleixner wrote:
>
> > Well, no. Look at the callchain:
> >
> > __call_rcu
> > debug_object_activate
> >rcuhead_fixup_activate
> > debug_object_init
> > kmem_cache_alloc
> >
> > So call
On Thu, 19 Jun 2014, Thomas Gleixner 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
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
> > On Thu, 19 Jun 2014, Sasha Levin wrote:
> >
> > > [ 690.770137] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> > > [ 690.770137] __slab_alloc (mm/slub.c:1732
On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
> On Thu, 19 Jun 2014, Sasha Levin wrote:
>
> > [ 690.770137] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> > [ 690.770137] __slab_alloc (mm/slub.c:1732 mm/slub.c:2205 mm/slub.c:2369)
> > [ 690.770137] ?
On Thu, 19 Jun 2014, Sasha Levin wrote:
> [ 690.770137] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> [ 690.770137] __slab_alloc (mm/slub.c:1732 mm/slub.c:2205 mm/slub.c:2369)
> [ 690.770137] ? __lock_acquire (kernel/locking/lockdep.c:3189)
> [ 690.770137] ? __debug_object_init
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew. It seems to cause an actual lockup
as hung task messages followed soon after.
[ 690.762537] =
[ 690.764196] [ INFO:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew. It seems to cause an actual lockup
as hung task messages followed soon after.
[ 690.762537] =
[ 690.764196] [ INFO:
On Thu, 19 Jun 2014, Sasha Levin wrote:
[ 690.770137] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 690.770137] __slab_alloc (mm/slub.c:1732 mm/slub.c:2205 mm/slub.c:2369)
[ 690.770137] ? __lock_acquire (kernel/locking/lockdep.c:3189)
[ 690.770137] ? __debug_object_init
On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
On Thu, 19 Jun 2014, Sasha Levin wrote:
[ 690.770137] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 690.770137] __slab_alloc (mm/slub.c:1732 mm/slub.c:2205 mm/slub.c:2369)
[ 690.770137] ? __lock_acquire
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
On Thu, 19 Jun 2014, Sasha Levin wrote:
[ 690.770137] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 690.770137] __slab_alloc (mm/slub.c:1732 mm/slub.c:2205
On Thu, 19 Jun 2014, Thomas Gleixner 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
On Thu, 19 Jun 2014, Christoph Lameter wrote:
On Thu, 19 Jun 2014, Thomas Gleixner 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
On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas Gleixner wrote:
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
On Thu, 19 Jun 2014, Sasha Levin wrote:
[ 690.770137] ? __this_cpu_preempt_check
On 06/19/2014 04:29 PM, 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:
On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter wrote:
On Thu, 19 Jun 2014, Sasha Levin wrote:
[
On Thu, Jun 19, 2014 at 03:19:39PM -0500, Christoph Lameter wrote:
On Thu, 19 Jun 2014, Thomas Gleixner wrote:
Well, no. Look at the callchain:
__call_rcu
debug_object_activate
rcuhead_fixup_activate
debug_object_init
kmem_cache_alloc
So call
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
On Thu, Jun 19, 2014 at 04:32:38PM -0400, Sasha Levin wrote:
On 06/19/2014 04:29 PM, 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:
On Thu, Jun 19, 2014 at 10:03:04AM -0500, Christoph Lameter
On 06/19/2014 04:29 PM, Paul E. McKenney wrote:
rcu: Provide call_rcu_alloc() and call_rcu_sched_alloc() to avoid recursion
The sl*b allocators use call_rcu() to manage object lifetimes, but
call_rcu() can use debug-objects, which in turn invokes the sl*b
allocators. These allocators are
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
On Thu, Jun 19, 2014 at 04:42:11PM -0400, Sasha Levin wrote:
On 06/19/2014 04:29 PM, Paul E. McKenney wrote:
rcu: Provide call_rcu_alloc() and call_rcu_sched_alloc() to avoid recursion
The sl*b allocators use call_rcu() to manage object lifetimes, but
call_rcu() can use debug-objects,
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
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
56 matches
Mail list logo
