Re: "locking/lockdep: Consolidate lock usage bit initialization" is buggy

Thanks for the further validation. On Fri, 7 Jun 2019 at 22:14, Qian Cai wrote: > 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 >

Re: "locking/lockdep: Consolidate lock usage bit initialization" is buggy

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 wrote: > > > > The linux-next commit "locking/lockdep: Consolidate lock usage bit > > initialization" [1] will always generate a warning below. > > I never had such

Re: "locking/lockdep: Consolidate lock usage bit initialization" is buggy

Thanks for the report, but On Fri, 7 Jun 2019 at 05:14, Qian Cai 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

"locking/lockdep: Consolidate lock usage bit initialization" is buggy

The linux-next commit "locking/lockdep: Consolidate lock usage bit initialization" [1] will always generate a warning below. 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. [1]