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

From: Andrew Morton
Date: Fri Jun 23 2006 - 06:40:48 EST


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/