[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200224101050.GE14897@hirez.programming.kicks-ass.net>
Date: Mon, 24 Feb 2020 11:10:50 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Joel Fernandes <joel@...lfernandes.org>
Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
rostedt@...dmis.org, mingo@...nel.org, gregkh@...uxfoundation.org,
gustavo@...eddedor.com, tglx@...utronix.de, paulmck@...nel.org,
josh@...htriplett.org, mathieu.desnoyers@...icios.com,
jiangshanlai@...il.com, luto@...nel.org, tony.luck@...el.com,
frederic@...nel.org, dan.carpenter@...cle.com, mhiramat@...nel.org
Subject: Re: [PATCH v4 01/27] lockdep: Teach lockdep about "USED" <- "IN-NMI"
inversions
On Fri, Feb 21, 2020 at 10:08:43PM -0500, Joel Fernandes wrote:
> On Fri, Feb 21, 2020 at 02:34:17PM +0100, Peter Zijlstra wrote:
> > nmi_enter() does lockdep_off() and hence lockdep ignores everything.
> >
> > And NMI context makes it impossible to do full IN-NMI tracking like we
> > do IN-HARDIRQ, that could result in graph_lock recursion.
>
> The patch makes sense to me.
>
> Reviewed-by: Joel Fernandes (Google) <joel@...lfernandes.org>
>
> NOTE:
> Also, I was wondering if we can detect the graph_lock recursion case and
> avoid doing anything bad, that way we enable more of the lockdep
> functionality for NMI where possible. Not sure if the suggestion makes sense
> though!
Yeah, I considered playing trylock games, but figured I shouldn't make
it more complicated that it needs to be.
Powered by blists - more mailing lists