Messages in this thread | | | Subject | Re: "locking/lockdep: Consolidate lock usage bit initialization" is buggy | From | Qian Cai <> | Date | Fri, 07 Jun 2019 10:14:46 -0400 |
| |
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 <cai@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
| |