From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Eric Dumazet <edumazet@google.com>,
Marco Elver <elver@google.com>,
LKML <linux-kernel@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] random32: Use rcuidle variant for tracepoint
Date: Fri, 21 Aug 2020 20:38:59 +0200 [thread overview]
Message-ID: <20200821183859.GS3982@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20200821114141.4b564190@oasis.local.home>
On Fri, Aug 21, 2020 at 11:41:41AM -0400, Steven Rostedt wrote:
> On Fri, 21 Aug 2020 11:38:31 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > > > At some point we're going to have to introduce noinstr to idle as well.
> > > > But until that time this should indeed cure things.
> > >
>
> What the above means, is that ideally we will get rid of all
> tracepoints and kasan checks from these RCU not watching locations. But
s/and kasan//
We only need to get rid of explicit tracepoints -- typically just move
them outside of the rcu_idle_enter/exit section.
> to do so, we need to move the RCU not watching as close as possible to
> where it doesn't need to be watching, and that is not as trivial of a
> task as one might think.
My recent patch series got a fair way towards that, but yes, there's
more work to be done still.
> Once we get to a minimal code path for RCU not
> to be watching, it will become "noinstr" and tracing and "debugging"
> will be disabled in these sections.
Right, noinstr is like notrace on steriods, not only does it disallow
tracing, it will also disable all the various *SAN/KCOV instrumentation.
It also has objtool based validation which ensures noinstr code doesn't
call out to regular code.
next prev parent reply other threads:[~2020-08-21 18:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 6:30 [PATCH] random32: Use rcuidle variant for tracepoint Marco Elver
2020-08-21 8:58 ` Marco Elver
2020-08-21 8:59 ` peterz
2020-08-21 15:06 ` Eric Dumazet
2020-08-21 15:35 ` Marco Elver
2020-09-18 1:21 ` Steven Rostedt
2020-08-21 15:38 ` Steven Rostedt
2020-08-21 15:41 ` Steven Rostedt
2020-08-21 18:38 ` Peter Zijlstra [this message]
2020-10-09 7:58 ` [tip: locking/core] kcsan: Use tracing-safe version of prandom tip-bot2 for Marco Elver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200821183859.GS3982@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=elver@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.