Re: [patch 50/61] lock validator: special locking: hrtimer.c

[Andrew Morton]

On Fri, 23 Jun 2006 12:04:39 +0200
Ingo Molnar <mingo@xxxxxxx> wrote:

> 
> * Andrew Morton <akpm@xxxxxxxx> wrote:
> 
> > >  	for (i = 0; i < MAX_HRTIMER_BASES; i++, base++)
> > > -		spin_lock_init(&base->lock);
> > > +		spin_lock_init_static(&base->lock);
> > >  }
> > >  
> > 
> > Perhaps the validator core's implementation of spin_lock_init() could 
> > look at the address and work out if it's within the static storage 
> > sections.
> 
> yeah, but there are two cases: places where we want to 'unify' array 
> locks into a single type, and places where we want to treat them 
> separately. The case where we 'unify' is the more common one: locks 
> embedded into hash-tables for example. So i went for annotating the ones 
> that are rarer. There are 2 right now: scheduler, hrtimers, with the 
> hrtimers one going away in the high-res-timers implementation. (we 
> unified the hrtimers locks into a per-CPU lock) (there's also a kgdb 
> annotation for -mm)
> 
> perhaps the naming should be clearer? I had it named 
> spin_lock_init_standalone() originally, then cleaned it up to be 
> spin_lock_init_static(). Maybe the original name is better?
> 

hm.  This is where a "term of art" is needed.  What is lockdep's internal
term for locks-of-a-different-type?  It should have such a term.

"class" would be a good term, although terribly overused.  Using that as an
example, spin_lock_init_standalone_class()?  ug.

<gives up>

You want spin_lock_init_singleton().
-
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/