Re: [patch 0/5] rcu head debugobjects

From: Mathieu Desnoyers
Date: Wed Apr 21 2010 - 21:20:59 EST


* Paul E. McKenney (paulmck@xxxxxxxxxxxxxxxxxx) wrote:
> On Sat, Apr 17, 2010 at 05:48:49PM -0700, Paul E. McKenney wrote:
> > On Sat, Apr 17, 2010 at 08:48:37AM -0400, Mathieu Desnoyers wrote:
> > > Here is a repost of the rcu head debugobjects patchset, with updated changelogs.
> > >
> > > Paul, this would be ready to be integrated with the RCU patches.
> >
> > Thank you, Mathieu, queued up for 2.6.35!
>
> And testing got me the following debugobjects splat, which baffles me.
> My first thought was that one of the synchronize_rcu() variants was
> missing the init_rcu_head_on_stack(), but not so. Then I started
> looking through the debugobjects code, and found the following:
>
> static void debug_object_is_on_stack(void *addr, int onstack)
> {
> int is_on_stack;
> static int limit;
>
> if (limit > 4)
> return;
>
> This really confuses me. We are using a static variable, but as
> near as I can tell, it is being guarded by a per-bucket lock:
>
> raw_spin_lock_irqsave(&db->lock, flags);
>
> If I understand correctly, this means that multiple CPUs might be
> concurrently updating the static variable "limit", which might in
> turn be causing the splat below.
>
> Or am I missing something?

This "limit" static variable is really only a printk suppressor: it stops the
printk warning output after approximately 5 occurences (modulo racy increments).
But normally, it should not _cause_ a splat if there ain't any in the first
place.

Will send the fix in a following email.

Thanks,

Mathieu

--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/