Re: [patch 0/5] rcu head debugobjects

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

* Paul E. McKenney (paulmck@linux.vnet.ibm.com) 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