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.
