Messages in this thread | | | Date | Tue, 8 Nov 2011 16:14:33 +0800 | From | Yong Zhang <> | Subject | Re: [PATCH 1/4] lockdep: lock_set_subclass() fix |
| |
On Tue, Nov 08, 2011 at 08:56:55AM +0100, Peter Zijlstra wrote: > On Tue, 2011-11-08 at 10:58 +0800, Yong Zhang wrote: > > > struct lockdep_map { > > > + const char *name; > > > struct lock_class_key *key; > > > struct lock_class *class_cache[NR_LOCKDEP_CACHING_CLASSES]; > > > - const char *name; > > > #ifdef CONFIG_LOCK_STAT > > > int cpu; > > > unsigned long ip; > > > diff --git a/kernel/lockdep.c b/kernel/lockdep.c > > > index e69434b..81855cf 100644 > > > --- a/kernel/lockdep.c > > > +++ b/kernel/lockdep.c > > > @@ -2948,7 +2948,8 @@ static int mark_lock(struct task_struct *curr, struct held_lock *this, > > > void lockdep_init_map(struct lockdep_map *lock, const char *name, > > > struct lock_class_key *key, int subclass) > > > { > > > - memset(lock, 0, sizeof(*lock)); > > > + kmemcheck_mark_initialized(lock, 2*sizeof(void *)); > > > + memset(&lock->class_cache[0], 0, sizeof(*lock)-2*sizeof(void *)); > > > > That means ->key have chance to be 0 at some time, right? > > How? We only memset from class_cache onwards, leaving name and key > untouched.
Hmm, we don't touch key in your patch. My eyes was keeping on ->name. Sorry.
But how do we deal with ->class_cache? Always set it in loop_up_lock_class()?
Thanks, Yong
| |