lkml.org 
[lkml]   [2010]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 0/5] rcu head debugobjects
* 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


\
 
 \ /
  Last update: 2010-04-22 03:23    [from the cache]
©2003-2011 Jasper Spaans