[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <269479609d444b2caebdc4d5d156bd5438a1899e.camel@redhat.com>
Date: Mon, 14 Sep 2020 18:04:08 -0400
From: Qian Cai <cai@...hat.com>
To: Boqun Feng <boqun.feng@...il.com>, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Jonathan Corbet <corbet@....net>,
Waiman Long <longman@...hat.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-next@...r.kernel.org
Subject: Re: [RFC v7 12/19] lockdep: Add recursive read locks into
dependency graph
On Mon, 2020-09-14 at 14:16 -0400, Qian Cai wrote:
> On Fri, 2020-08-07 at 15:42 +0800, Boqun Feng wrote:
> > Since we have all the fundamental to handle recursive read locks, we now
> > add them into the dependency graph.
> >
> > Signed-off-by: Boqun Feng <boqun.feng@...il.com>
>
> Reverting this patch and its dependency:
>
> [14/19] lockdep: Take read/write status in consideration when generate
> chainkey
>
> fixed a splat below. IOW, this patch introduced this new splat which looks
Sorry, it turned out my previous reproducer was not so reliable, but now I found
a new reliable reproducer that could trigger this on both x86 and powerpc every
time which so far points out the culprit being the patchset:
"[PATCH v1 0/5] seqlock: Introduce PREEMPT_RT support" [1].
It also matched exactly the exact timing (today) between the issue showed up and
the patchset was merged into linux-next. I'll do a bit more confirmation and
report it there.
[1] https://lore.kernel.org/lkml/20200828010710.5407-1-a.darwish@linutronix.de/
Powered by blists - more mailing lists