[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <X/Xa1fwplnZIOm+U@hirez.programming.kicks-ass.net>
Date: Wed, 6 Jan 2021 16:44:21 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: tglx@...utronix.de, linux-kernel@...r.kernel.org,
valentin.schneider@....com, bristot@...hat.com, frederic@...nel.org
Subject: Re: lockdep splat in v5.11-rc1 involving console_sem and rq locks
On Wed, Jan 06, 2021 at 06:46:21AM -0800, Paul E. McKenney wrote:
> Huh. The WARN does not always generate the lockdep complaint. But
> fair enough.
Any printk()/WARN/BUG with rq lock held ought to generate that splat,
sometimes we die before we splat. The printk rewrite should eventually
fix that.
> > https://lkml.kernel.org/r/20201226025117.2770-1-jiangshanlai@gmail.com
>
> Thomas pointed me at this one a couple of weeks ago. Here is an
> additional fix for rcutorture: f67e04bb0695 ("torture: Break affinity
> of kthreads last running on outgoing CPU"). I am still getting WARNs
> and lockdep splats with both applied.
That patch looks racy, what avoids the task being shuffled right back
before the CPU goes offline?
> What would break if I made the code dump out a few entries in the
> runqueue if the warning triggered?
There was a patch around that did that, Valentin might remember where
that was.
Powered by blists - more mailing lists