[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200212093235.2be06208@gandalf.local.home>
Date: Wed, 12 Feb 2020 09:32:34 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Will Deacon <will@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
james.morse@....com, catalin.marinas@....com, mingo@...nel.org,
joel@...lfernandes.org, gregkh@...uxfoundation.org,
gustavo@...eddedor.com, tglx@...utronix.de, paulmck@...nel.org,
josh@...htriplett.org, mathieu.desnoyers@...icios.com,
jiangshanlai@...il.com
Subject: Re: [PATCH 0/8] tracing vs rcu vs nmi
On Wed, 12 Feb 2020 10:56:46 +0000
Will Deacon <will@...nel.org> wrote:
> Hmm, so looks like we need to spinkle some 'notrace' annotations around
> these. Are there are scenarios where you would want NOKPROBE_SYMBOL() but
> *not* 'notrace'? We've already got the former for the debug exception
> handlers and we probably (?) want it for the SDEI stuff too...
Note, function tracing has a lot of recursion detection, and when
something registers with the function tracer it needs to state if it
can be called when rcu is not watching, or it wont be called then.
And yes, there's plenty of places that we have "nokprobe" but allow
tracing.
I've been trying to get rid of notrace around the kernel, not add more.
-- Steve
Powered by blists - more mailing lists