On 11/22/2018 10:33 AM, Petr Mladek wrote: > On Mon 2018-11-19 13:55:18, Waiman Long wrote: >> By making the object hash locks nestable terminal locks, we can avoid >> a bunch of unnecessary lockdep validations as well as saving space >> in the lockdep tables. > Please, explain which terminal lock might be nested. > > Hmm, it would hide eventual nesting of other terminal locks. > It might reduce lockdep reliability. I wonder if the space > optimization is worth it. > > Finally, it might be good to add a short explanation what (nested) > terminal locks mean into each commit. It would help people to > understand the effect without digging into the lockdep code, ... > > Best Regards, > Petr Nested terminal lock is currently only used in the debugobjects code. It should only be used on a case-by-case basis. In the case of the debugojects code, the locking patterns are: (1) raw_spin_lock(&db_lock); ... raw_spin_unlock(&db_lock); (2) raw_spin_lock(&db_lock); ... raw_spin_lock(&pool_lock); ... raw_spin_unlock(&pool_lock); ... raw_spin_unlock(&db_lock); (3) raw_spin_lock(&pool_lock); ... raw_spin_unlock(&pool_lock); So the db_lock is made to be nestable that it can allow acquisition of pool_lock (a regular terminal lock) underneath it. Cheers, Longman
