[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Apr 2016 11:01:43 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
"x86@...nel.org" <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Oleg Nesterov <oleg@...hat.com>,
syzkaller <syzkaller@...glegroups.com>,
Kostya Serebryany <kcc@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
Sasha Levin <sasha.levin@...cle.com>
Subject: Re: lockdep WARNING in get_online_cpus
On Mon, Apr 04, 2016 at 10:19:05AM +0200, Dmitry Vyukov wrote:
>
> This happens in CONFIG_DEBUG_LOCKDEP code. Is it a bug in lockdep?
We hope not; but it is a new test.
So lockdep needs to check each current lock stack against the recorded
lock dependencies to see if we've gotten ourselves a cycle. Doing this
check is _expensive_.
So what lockdep does is it computes a hash for each lock stack and only
if we've not seen this hash before (actually truncated since we don't
have a full 64bit hashtable) do we go look for cycles.
The new check tries to detect hash-collisions in this cache. A collision
would result in not checking for cycles, even if we've not seen the
stack before.
You've managed to tickle this.
Now, last week I found some bugs in there, and Alfredo added a pretty
printer, so maybe try and add these patches to your testing?
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/urgent
> But I always see at the same stack involving perf and jump_label...
So you have a simple reproducer? So that I can have a go at this.
Powered by blists - more mailing lists