From: Steven Rostedt <rostedt@goodmis.org>
To: Eiichi Tsukata <devel@etsukata.com>
Cc: joel@joelfernandes.org, paulmck@linux.vnet.ibm.com,
tglx@linutronix.de, peterz@infradead.org, mingo@redhat.com,
fweisbec@gmail.com, luto@amacapital.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing: Prevent RCU EQS breakage in preemptirq events
Date: Mon, 29 Jul 2019 22:15:06 -0400 [thread overview]
Message-ID: <20190729221506.1aed7dfc@oasis.local.home> (raw)
In-Reply-To: <2ceec933-503e-5d58-60b4-85b491b017d4@etsukata.com>
On Tue, 30 Jul 2019 11:00:42 +0900
Eiichi Tsukata <devel@etsukata.com> wrote:
> Thanks for comments.
>
> On 2019/07/30 0:21, Steven Rostedt wrote:
> > On Mon, 29 Jul 2019 10:07:34 +0900
> > Eiichi Tsukata <devel@etsukata.com> wrote:
> >
> >> If context tracking is enabled, causing page fault in preemptirq
> >> irq_enable or irq_disable events triggers the following RCU EQS warning.
> >>
> >> Reproducer:
> >>
> >> // CONFIG_PREEMPTIRQ_EVENTS=y
> >> // CONFIG_CONTEXT_TRACKING=y
> >> // CONFIG_RCU_EQS_DEBUG=y
> >> # echo 1 > events/preemptirq/irq_disable/enable
> >> # echo 1 > options/userstacktrace
> >
> > So the problem is only with userstacktrace enabled?
>
> It can happen when tracing code causes page fault in preemptirq events.
> For example, the following perf command also hit the warning:
>
> # perf record -e 'preemptirq:irq_enable' -g ls
Again,
That's not a irq trace event issue, that's a stack trace issue.
>
>
> >>
> >> __visible void trace_hardirqs_on_caller(unsigned long caller_addr)
> >> {
> >> + enum ctx_state prev_state;
> >> +
> >> if (this_cpu_read(tracing_irq_cpu)) {
> >> - if (!in_nmi())
> >> + if (!in_nmi()) {
> >
> > This is a very high fast path (for tracing irqs off and such). Instead
> > of adding a check here for a case that is seldom used (userstacktrace
> > and tracing irqs on/off). Move this to surround the userstack trace
> > code.
> >
> > -- Steve
>
> If the problem was only with userstacktrace, it will be reasonable to
> surround only the userstack unwinder. But the situation is similar to
> the previous "tracing vs CR2" case. As Peter taught me in
> https://lore.kernel.org/lkml/20190708074823.GV3402@hirez.programming.kicks-ass.net/
> there are some other codes likely to to user access.
> So I surround preemptirq events earlier.
I disagree. The issue is with the attached callbacks that call
something (a stack unwinder) that can fault.
This is called whenever irqs are disabled. I say we surround the
culprit (the stack unwinder or stack trace) and not punish the irq
enable/disable events.
So NAK on this patch.
-- Steve
next prev parent reply other threads:[~2019-07-30 2:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-29 1:07 [PATCH] tracing: Prevent RCU EQS breakage in preemptirq events Eiichi Tsukata
2019-07-29 4:25 ` Andy Lutomirski
2019-07-29 10:29 ` Peter Zijlstra
2019-07-30 1:50 ` Eiichi Tsukata
2019-07-30 1:59 ` Steven Rostedt
2019-07-29 15:21 ` Steven Rostedt
2019-07-30 2:00 ` Eiichi Tsukata
2019-07-30 2:15 ` Steven Rostedt [this message]
2019-07-30 4:19 ` Joel Fernandes
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=20190729221506.1aed7dfc@oasis.local.home \
--to=rostedt@goodmis.org \
--cc=devel@etsukata.com \
--cc=fweisbec@gmail.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).