On Fri, 2019-06-07 at 11:21 +0800, Yuyang Du wrote: > Thanks for the report, but > > On Fri, 7 Jun 2019 at 05:14, Qian Cai <c...@lca.pw> wrote: > > > > The linux-next commit "locking/lockdep: Consolidate lock usage bit > > initialization" [1] will always generate a warning below. > > I never had such warning. > > > Looking through the > > commit that when mark_irqflags() returns 1 and check = 1, it will do one > > less > > mark_lock() call than it used to. > > The four cases: > > 1. When check == 1 and mark_irqflags() returns 1; > 2. When check == 1 and mark_irqflags() returns 0; > 3. When check == 0 and mark_irqflags() returns 1; > 4. When check == 0 and mark_irqflags() returns 0; > > Before and after have exactly the same code to do.
Reverted the commit on the top of linux-next fixed the issue. With the commit (triggering the warning DEBUG_LOCKS_WARN_ON(debug_atomic_read(nr_unused_locks) != nr_unused)), # cat /proc/lockdep_stats lock-classes: 1110 [max: 8192] stack-trace entries: 0 [max: 524288] combined max dependencies: 1 uncategorized locks: 0 unused locks: 1110 max locking depth: 14 debug_locks: 0 Without the commit (no warning), # cat /proc/lockdep_stats lock-classes: 1110 [max: 8192] stack-trace entries: 9932 [max: 524288] combined max dependencies: 1 uncategorized locks: 1113 unused locks: 0 max locking depth: 14 debug_locks: 1
