From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: John Stultz <john.stultz@linaro.org>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Steven Rostedt <rostedt@goodmis.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Suspicious RCU usage at boot w/ arm ipi trace events?
Date: Wed, 17 Jun 2015 19:33:52 -0700 [thread overview]
Message-ID: <20150618023352.GW3913@linux.vnet.ibm.com> (raw)
In-Reply-To: <558223B2.5030204@codeaurora.org>
On Wed, Jun 17, 2015 at 06:49:38PM -0700, Stephen Boyd wrote:
> On 06/16/2015 09:46 PM, Paul E. McKenney wrote:
> > On Tue, Jun 16, 2015 at 05:41:29PM -0700, Stephen Boyd wrote:
> >>
> >> The tracepoint 'trace_ipi_entry' in handle_IPI() is using RCU and we
> >> haven't called irq_enter() yet at the point. Does this tracepoint need
> >> to have _rcuidle() added to it?
> > Yes, I believe that would fix this problem.
> >
>
> Ok... here's the patch. I see the problem on my device and applying this
> patch fixes it.
>
> ----8<----
>
> From: Stephen Boyd <sboyd@codeaurora.org>
> Subject: [PATCH] ARM: smp: Silence suspicious RCU usage with ipi tracepoints
>
> John Stultz reports an RCU splat on boot with ARM ipi trace
> events enabled.
>
> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.1.0-rc7-00033-gb5bed2f #153 Not tainted
> -------------------------------
> include/trace/events/ipi.h:68 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> no locks held by swapper/0/0.
>
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc7-00033-gb5bed2f #153
> Hardware name: Qualcomm (Flattened Device Tree)
> [<c0216b08>] (unwind_backtrace) from [<c02136e8>] (show_stack+0x10/0x14)
> [<c02136e8>] (show_stack) from [<c075e678>] (dump_stack+0x70/0xbc)
> [<c075e678>] (dump_stack) from [<c0215a80>] (handle_IPI+0x428/0x604)
> [<c0215a80>] (handle_IPI) from [<c020942c>] (gic_handle_irq+0x54/0x5c)
> [<c020942c>] (gic_handle_irq) from [<c0766604>] (__irq_svc+0x44/0x7c)
> Exception stack(0xc09f3f48 to 0xc09f3f90)
> 3f40: 00000001 00000001 00000000 c09f73b8 c09f4528 c0a5de9c
> 3f60: c076b4f0 00000000 00000000 c09ef108 c0a5cec1 00000001 00000000 c09f3f90
> 3f80: c026bf60 c0210ab8 20000113 ffffffff
> [<c0766604>] (__irq_svc) from [<c0210ab8>] (arch_cpu_idle+0x20/0x3c)
> [<c0210ab8>] (arch_cpu_idle) from [<c02647f0>] (cpu_startup_entry+0x2c0/0x5dc)
> [<c02647f0>] (cpu_startup_entry) from [<c099bc1c>] (start_kernel+0x358/0x3c4)
> [<c099bc1c>] (start_kernel) from [<8020807c>] (0x8020807c)
>
> At this point in the IPI handling path we haven't called
> irq_enter() yet, so RCU doesn't know that we're about to exit
> idle and properly warns that we're using RCU from an idle CPU.
> Use trace_ipi_entry_rcuidle() instead of trace_ipi_entry() so
> that RCU is informed about our exit from idle.
>
> Reported-by: John Stultz <john.stultz@linaro.org>
> Fixes: 365ec7b17327 "ARM: add IPI tracepoints"
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
> arch/arm/kernel/smp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 13a91d390832..03eb8a446dca 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -589,7 +589,7 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
> struct pt_regs *old_regs = set_irq_regs(regs);
>
> if ((unsigned)ipinr < NR_IPI) {
> - trace_ipi_entry(ipi_types[ipinr]);
> + trace_ipi_entry_rcuidle(ipi_types[ipinr]);
> __inc_irq_stat(cpu, ipi_irqs[ipinr]);
> }
>
> @@ -648,7 +648,7 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
> }
>
> if ((unsigned)ipinr < NR_IPI)
> - trace_ipi_exit(ipi_types[ipinr]);
> + trace_ipi_exit_rcuidle(ipi_types[ipinr]);
> set_irq_regs(old_regs);
> }
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
next prev parent reply other threads:[~2015-06-18 2:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-17 0:21 Suspicious RCU usage at boot w/ arm ipi trace events? John Stultz
2015-06-17 0:31 ` Paul E. McKenney
2015-06-17 0:41 ` Stephen Boyd
2015-06-17 4:46 ` Paul E. McKenney
2015-06-18 1:49 ` Stephen Boyd
2015-06-18 2:33 ` Paul E. McKenney [this message]
2015-06-18 3:25 ` Steven Rostedt
2015-06-18 21:57 ` John Stultz
2015-06-19 18:49 ` Stephen Boyd
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=20150618023352.GW3913@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=rostedt@goodmis.org \
--cc=sboyd@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox