| Message ID | 1541709268-3766-2-git-send-email-longman@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | locking/lockdep: Add a new class of terminal locks | expand |
On Thu, Nov 08, 2018 at 03:34:17PM -0500, Waiman Long wrote: > The current lockdep_set_novalidate_class() implementation is like > a hack. It assigns a special class key for that lock and calls > lockdep_init_map() twice. Ideally it would go away.. it is not thing that should be used. > This patch changes the implementation to make it more general so that > it can be used by other special lock class types. A new "type" field > is added to both the lockdep_map and lock_class structures. > > The new field can now be used to designate a lock and a class object > as novalidate. The lockdep_set_novalidate_class() call, however, should > be called before lock initialization which calls lockdep_init_map(). I don't really feel like this is something that should be made easier or better. > @@ -102,6 +100,8 @@ struct lock_class { > int name_version; > const char *name; > > + unsigned int flags; > + > #ifdef CONFIG_LOCK_STAT > unsigned long contention_point[LOCKSTAT_POINTS]; > unsigned long contending_point[LOCKSTAT_POINTS]; Esp. not at the cost of growing the data structures.
On 11/10/2018 09:14 AM, Peter Zijlstra wrote: > On Thu, Nov 08, 2018 at 03:34:17PM -0500, Waiman Long wrote: >> The current lockdep_set_novalidate_class() implementation is like >> a hack. It assigns a special class key for that lock and calls >> lockdep_init_map() twice. > Ideally it would go away.. it is not thing that should be used. Yes, I agree. Right now, lockdep_set_novalidate_class() is used in drivers/base/core.c: lockdep_set_novalidate_class(&dev->mutex); drivers/md/bcache/btree.c: lockdep_set_novalidate_class(&b->lock); drivers/md/bcache/btree.c: lockdep_set_novalidate_class(&b->write_lock); Do you know the history behind making them novalidate? > >> This patch changes the implementation to make it more general so that >> it can be used by other special lock class types. A new "type" field >> is added to both the lockdep_map and lock_class structures. >> >> The new field can now be used to designate a lock and a class object >> as novalidate. The lockdep_set_novalidate_class() call, however, should >> be called before lock initialization which calls lockdep_init_map(). > I don't really feel like this is something that should be made easier or > better. I am not saying that this patch make lockdep_set_novalidate_class() easier to use. It is that terminal locks will share similar code path and so I rework it so that they can checked together in one test instead of 2 separate tests. >> @@ -102,6 +100,8 @@ struct lock_class { >> int name_version; >> const char *name; >> >> + unsigned int flags; >> + >> #ifdef CONFIG_LOCK_STAT >> unsigned long contention_point[LOCKSTAT_POINTS]; >> unsigned long contending_point[LOCKSTAT_POINTS]; > Esp. not at the cost of growing the data structures. > > I did reduce the size by 16 bytes for 64-bit architecture in my previous lockdep patch. Now I claw back 8 bytes for this new functionality. Cheers, Longman
On Sat, Nov 10, 2018 at 07:26:51PM -0500, Waiman Long wrote: > On 11/10/2018 09:14 AM, Peter Zijlstra wrote: > > On Thu, Nov 08, 2018 at 03:34:17PM -0500, Waiman Long wrote: > >> The current lockdep_set_novalidate_class() implementation is like > >> a hack. It assigns a special class key for that lock and calls > >> lockdep_init_map() twice. > > Ideally it would go away.. it is not thing that should be used. > > Yes, I agree. Right now, lockdep_set_novalidate_class() is used in > > drivers/base/core.c: lockdep_set_novalidate_class(&dev->mutex); > drivers/md/bcache/btree.c: lockdep_set_novalidate_class(&b->lock); > drivers/md/bcache/btree.c: > lockdep_set_novalidate_class(&b->write_lock); > > Do you know the history behind making them novalidate? Only of the driver/base/core.c one; there the locking order depends on the hardware and we never quite found a way to annotate that sanely. I forgot most details though. The other stuff I only 'recently' found out about :-( And ideally would have never made it into the tree, but alas.
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h index 1fd82ff..18f9607 100644 --- a/include/linux/lockdep.h +++ b/include/linux/lockdep.h @@ -58,8 +58,6 @@ struct lock_class_key { struct lockdep_subclass_key subkeys[MAX_LOCKDEP_SUBCLASSES]; }; -extern struct lock_class_key __lockdep_no_validate__; - #define LOCKSTAT_POINTS 4 /* @@ -102,6 +100,8 @@ struct lock_class { int name_version; const char *name; + unsigned int flags; + #ifdef CONFIG_LOCK_STAT unsigned long contention_point[LOCKSTAT_POINTS]; unsigned long contending_point[LOCKSTAT_POINTS]; @@ -142,6 +142,12 @@ struct lock_class_stats { #endif /* + * Lockdep class flags + * 1) LOCKDEP_FLAG_NOVALIDATE: No full validation, just simple checks. + */ +#define LOCKDEP_FLAG_NOVALIDATE (1 << 0) + +/* * Map the lock object (the lock instance) to the lock-class object. * This is embedded into specific lock instances: */ @@ -149,6 +155,7 @@ struct lockdep_map { struct lock_class_key *key; struct lock_class *class_cache[NR_LOCKDEP_CACHING_CLASSES]; const char *name; + unsigned int flags; #ifdef CONFIG_LOCK_STAT int cpu; unsigned long ip; @@ -296,7 +303,8 @@ extern void lockdep_init_map(struct lockdep_map *lock, const char *name, (lock)->dep_map.key, sub) #define lockdep_set_novalidate_class(lock) \ - lockdep_set_class_and_name(lock, &__lockdep_no_validate__, #lock) + do { (lock)->dep_map.flags |= LOCKDEP_FLAG_NOVALIDATE; } while (0) + /* * Compare locking classes */ diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 1efada2..493b567 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -692,10 +692,11 @@ static int count_matching_names(struct lock_class *new_class) hlist_for_each_entry_rcu(class, hash_head, hash_entry) { if (class->key == key) { /* - * Huh! same key, different name? Did someone trample - * on some memory? We're most confused. + * Huh! same key, different name or flags? Did someone + * trample on some memory? We're most confused. */ - WARN_ON_ONCE(class->name != lock->name); + WARN_ON_ONCE((class->name != lock->name) || + (class->flags != lock->flags)); return class; } } @@ -788,6 +789,7 @@ static bool assign_lock_key(struct lockdep_map *lock) debug_atomic_inc(nr_unused_locks); class->key = key; class->name = lock->name; + class->flags = lock->flags; class->subclass = subclass; INIT_LIST_HEAD(&class->lock_entry); INIT_LIST_HEAD(&class->locks_before); @@ -3108,6 +3110,7 @@ static void __lockdep_init_map(struct lockdep_map *lock, const char *name, return; } + lock->flags = 0; lock->name = name; /* @@ -3152,9 +3155,6 @@ void lockdep_init_map(struct lockdep_map *lock, const char *name, } EXPORT_SYMBOL_GPL(lockdep_init_map); -struct lock_class_key __lockdep_no_validate__; -EXPORT_SYMBOL_GPL(__lockdep_no_validate__); - static int print_lock_nested_lock_not_held(struct task_struct *curr, struct held_lock *hlock, @@ -3215,7 +3215,7 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass, if (unlikely(!debug_locks)) return 0; - if (!prove_locking || lock->key == &__lockdep_no_validate__) + if (!prove_locking || (lock->flags & LOCKDEP_FLAG_NOVALIDATE)) check = 0; if (subclass < NR_LOCKDEP_CACHING_CLASSES)
The current lockdep_set_novalidate_class() implementation is like a hack. It assigns a special class key for that lock and calls lockdep_init_map() twice. This patch changes the implementation to make it more general so that it can be used by other special lock class types. A new "type" field is added to both the lockdep_map and lock_class structures. The new field can now be used to designate a lock and a class object as novalidate. The lockdep_set_novalidate_class() call, however, should be called before lock initialization which calls lockdep_init_map(). Signed-off-by: Waiman Long <longman@redhat.com> --- include/linux/lockdep.h | 14 +++++++++++--- kernel/locking/lockdep.c | 14 +++++++------- 2 files changed, 18 insertions(+), 10 deletions(-)