[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHttsrZN09-_GXujv2H5gAORLHcO2onrotFND5GrDXRGRtFpJQ@mail.gmail.com>
Date: Mon, 10 Jun 2019 10:23:18 +0800
From: Yuyang Du <duyuyang@...il.com>
To: Qian Cai <cai@....pw>
Cc: "Peter Zijlstra (Intel)" <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: 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 <cai@....pw> 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
> 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
Then it is obviously we are talking on different things; then it is
obviously a configuration problem. Fix will be posted soon.
Sorry the bug.
Thanks,
Yuyang
Powered by blists - more mailing lists