[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160516175735.GS3193@twins.programming.kicks-ass.net>
Date: Mon, 16 May 2016 19:57:35 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Sedat Dilek <sedat.dilek@...il.com>
Cc: Ingo Molnar <mingo@...nel.org>, David Miller <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [v4.6-rc7-183-g1410b74e4061]
On Mon, May 16, 2016 at 07:42:35PM +0200, Sedat Dilek wrote:
> Unfortunately, I could not reproduce this again with none of my 183-kernels.
> When I first hit a "chain_key collision" issue, it was hard to redproduce, so.
> Any idea, how I can "force" this?
Nope; I wish I knew, that'd be so much easier to work with :/
I'm hoping someone will report a reproducer, even something that
triggers once every 5-10 runs would be awesome.
In any case, like I've explained before, nothing regressed as such, we
only added this new warning under DEBUG_LOCKDEP because we want to
better understand the condition that triggers it.
If it bothers you, just turn off DEBUG_LOCKDEP and know that your kernel
is as reliable as it was before. OTOH, if you do keep it on, please
let me know if you can (semi) reliably trigger this, as I'd really like
to have a better understanding.
Powered by blists - more mailing lists