* RCU splat on boot from an idle CPU
@ 2015-09-01 0:46 Philipp Schrader
2015-09-01 15:35 ` Thomas Gleixner
0 siblings, 1 reply; 13+ messages in thread
From: Philipp Schrader @ 2015-09-01 0:46 UTC (permalink / raw)
To: linux-rt-users
Hi all,
I've got a real-time kernel on a DRA7 evaluation module (EVM).
Very early in the boot process I get the following splat.
[ 0.055073]
[ 0.055076] ===============================
[ 0.055079] [ INFO: suspicious RCU usage. ]
[ 0.055084] 4.1.6+ #2 Not tainted
[ 0.055086] -------------------------------
[ 0.055090] include/trace/events/hist.h:31 suspicious
rcu_dereference_check() usage!
[ 0.055093]
[ 0.055093] other info that might help us debug this:
[ 0.055093]
[ 0.055097]
[ 0.055097] RCU used illegally from idle CPU!
[ 0.055097] rcu_scheduler_active = 1, debug_locks = 1
[ 0.055100] RCU used illegally from extended quiescent state!
[ 0.055104] no locks held by swapper/0/0.
[ 0.055106]
[ 0.055106] stack backtrace:
[ 0.055112] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.6+ #2
[ 0.055116] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 0.055130] [<c00196b8>] (unwind_backtrace) from [<c001515c>]
(show_stack+0x20/0x24)
[ 0.055146] [<c001515c>] (show_stack) from [<c07bc408>]
(dump_stack+0x84/0xa0)
[ 0.055160] [<c07bc408>] (dump_stack) from [<c009bc38>]
(lockdep_rcu_suspicious+0xb0/0x110)
[ 0.055172] [<c009bc38>] (lockdep_rcu_suspicious) from [<c01246c4>]
(time_hardirqs_off+0x2b8/0x3c8)
[ 0.055184] [<c01246c4>] (time_hardirqs_off) from [<c009a218>]
(trace_hardirqs_off_caller+0x2c/0xf4)
[ 0.055194] [<c009a218>] (trace_hardirqs_off_caller) from
[<c009a2f4>] (trace_hardirqs_off+0x14/0x18)
[ 0.055204] [<c009a2f4>] (trace_hardirqs_off) from [<c00c7ecc>]
(rcu_idle_enter+0x78/0xcc)
[ 0.055213] [<c00c7ecc>] (rcu_idle_enter) from [<c0093eb0>]
(cpu_startup_entry+0x190/0x518)
[ 0.055222] [<c0093eb0>] (cpu_startup_entry) from [<c07b95b4>]
(rest_init+0x13c/0x17c)
[ 0.055231] [<c07b95b4>] (rest_init) from [<c0b32c74>]
(start_kernel+0x320/0x380)
[ 0.055238] [<c0b32c74>] (start_kernel) from [<8000807c>] (0x8000807c)
I'm not sure how to debug this; I'm still reading up on RCUs. Pretty
nifty ideas.
Looking at include/trace/events/hist.h it appears line 31 is the end
of a TRACE_EVENT macro usage.
Does that mean the macro is using RCU improperly somehow?
Thanks,
Philipp
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-09-01 0:46 RCU splat on boot from an idle CPU Philipp Schrader
@ 2015-09-01 15:35 ` Thomas Gleixner
2015-09-02 19:38 ` Steven Rostedt
0 siblings, 1 reply; 13+ messages in thread
From: Thomas Gleixner @ 2015-09-01 15:35 UTC (permalink / raw)
To: Philipp Schrader; +Cc: linux-rt-users
On Mon, 31 Aug 2015, Philipp Schrader wrote:
Cc'ing Paul and Steven
> Hi all,
>
> I've got a real-time kernel on a DRA7 evaluation module (EVM).
> Very early in the boot process I get the following splat.
>
> [ 0.055073]
> [ 0.055076] ===============================
> [ 0.055079] [ INFO: suspicious RCU usage. ]
> [ 0.055084] 4.1.6+ #2 Not tainted
> [ 0.055086] -------------------------------
> [ 0.055090] include/trace/events/hist.h:31 suspicious
> rcu_dereference_check() usage!
> [ 0.055093]
> [ 0.055093] other info that might help us debug this:
> [ 0.055093]
> [ 0.055097]
> [ 0.055097] RCU used illegally from idle CPU!
> [ 0.055097] rcu_scheduler_active = 1, debug_locks = 1
> [ 0.055100] RCU used illegally from extended quiescent state!
> [ 0.055104] no locks held by swapper/0/0.
> [ 0.055106]
> [ 0.055106] stack backtrace:
> [ 0.055112] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.6+ #2
> [ 0.055116] Hardware name: Generic DRA74X (Flattened Device Tree)
> [ 0.055130] [<c00196b8>] (unwind_backtrace) from [<c001515c>]
> (show_stack+0x20/0x24)
> [ 0.055146] [<c001515c>] (show_stack) from [<c07bc408>]
> (dump_stack+0x84/0xa0)
> [ 0.055160] [<c07bc408>] (dump_stack) from [<c009bc38>]
> (lockdep_rcu_suspicious+0xb0/0x110)
> [ 0.055172] [<c009bc38>] (lockdep_rcu_suspicious) from [<c01246c4>]
> (time_hardirqs_off+0x2b8/0x3c8)
> [ 0.055184] [<c01246c4>] (time_hardirqs_off) from [<c009a218>]
> (trace_hardirqs_off_caller+0x2c/0xf4)
> [ 0.055194] [<c009a218>] (trace_hardirqs_off_caller) from
> [<c009a2f4>] (trace_hardirqs_off+0x14/0x18)
> [ 0.055204] [<c009a2f4>] (trace_hardirqs_off) from [<c00c7ecc>]
> (rcu_idle_enter+0x78/0xcc)
> [ 0.055213] [<c00c7ecc>] (rcu_idle_enter) from [<c0093eb0>]
> (cpu_startup_entry+0x190/0x518)
> [ 0.055222] [<c0093eb0>] (cpu_startup_entry) from [<c07b95b4>]
> (rest_init+0x13c/0x17c)
> [ 0.055231] [<c07b95b4>] (rest_init) from [<c0b32c74>]
> (start_kernel+0x320/0x380)
> [ 0.055238] [<c0b32c74>] (start_kernel) from [<8000807c>] (0x8000807c)
>
> I'm not sure how to debug this; I'm still reading up on RCUs. Pretty
> nifty ideas.
>
> Looking at include/trace/events/hist.h it appears line 31 is the end
> of a TRACE_EVENT macro usage.
> Does that mean the macro is using RCU improperly somehow?
>
> Thanks,
> Philipp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-09-01 15:35 ` Thomas Gleixner
@ 2015-09-02 19:38 ` Steven Rostedt
2015-09-02 22:10 ` Philipp Schrader
0 siblings, 1 reply; 13+ messages in thread
From: Steven Rostedt @ 2015-09-02 19:38 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Philipp Schrader, linux-rt-users, Paul E. McKenney
On Tue, 1 Sep 2015 17:35:23 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 31 Aug 2015, Philipp Schrader wrote:
>
> Cc'ing Paul and Steven
Not sure if we were actually Cc'd (reading this from my
linux-rt-users folder)
>
> > Hi all,
> >
> > I've got a real-time kernel on a DRA7 evaluation module (EVM).
> > Very early in the boot process I get the following splat.
> >
> > [ 0.055073]
> > [ 0.055076] ===============================
> > [ 0.055079] [ INFO: suspicious RCU usage. ]
> > [ 0.055084] 4.1.6+ #2 Not tainted
> > [ 0.055086] -------------------------------
> > [ 0.055090] include/trace/events/hist.h:31 suspicious
Hmm, the histogram code in -rt, needs a rewrite :-/ I haven't had time
to do so. But it's definitely on my TODO list.
> > rcu_dereference_check() usage!
> > [ 0.055093]
> > [ 0.055093] other info that might help us debug this:
> > [ 0.055093]
> > [ 0.055097]
> > [ 0.055097] RCU used illegally from idle CPU!
> > [ 0.055097] rcu_scheduler_active = 1, debug_locks = 1
> > [ 0.055100] RCU used illegally from extended quiescent state!
> > [ 0.055104] no locks held by swapper/0/0.
> > [ 0.055106]
> > [ 0.055106] stack backtrace:
> > [ 0.055112] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.6+ #2
> > [ 0.055116] Hardware name: Generic DRA74X (Flattened Device Tree)
> > [ 0.055130] [<c00196b8>] (unwind_backtrace) from [<c001515c>]
> > (show_stack+0x20/0x24)
> > [ 0.055146] [<c001515c>] (show_stack) from [<c07bc408>]
> > (dump_stack+0x84/0xa0)
> > [ 0.055160] [<c07bc408>] (dump_stack) from [<c009bc38>]
> > (lockdep_rcu_suspicious+0xb0/0x110)
> > [ 0.055172] [<c009bc38>] (lockdep_rcu_suspicious) from [<c01246c4>]
> > (time_hardirqs_off+0x2b8/0x3c8)
> > [ 0.055184] [<c01246c4>] (time_hardirqs_off) from [<c009a218>]
> > (trace_hardirqs_off_caller+0x2c/0xf4)
> > [ 0.055194] [<c009a218>] (trace_hardirqs_off_caller) from
> > [<c009a2f4>] (trace_hardirqs_off+0x14/0x18)
> > [ 0.055204] [<c009a2f4>] (trace_hardirqs_off) from [<c00c7ecc>]
> > (rcu_idle_enter+0x78/0xcc)
> > [ 0.055213] [<c00c7ecc>] (rcu_idle_enter) from [<c0093eb0>]
> > (cpu_startup_entry+0x190/0x518)
> > [ 0.055222] [<c0093eb0>] (cpu_startup_entry) from [<c07b95b4>]
> > (rest_init+0x13c/0x17c)
> > [ 0.055231] [<c07b95b4>] (rest_init) from [<c0b32c74>]
> > (start_kernel+0x320/0x380)
> > [ 0.055238] [<c0b32c74>] (start_kernel) from [<8000807c>] (0x8000807c)
> >
> > I'm not sure how to debug this; I'm still reading up on RCUs. Pretty
> > nifty ideas.
> >
> > Looking at include/trace/events/hist.h it appears line 31 is the end
> > of a TRACE_EVENT macro usage.
> > Does that mean the macro is using RCU improperly somehow?
I think this needs to be a trace_*_rcu_idle() call. That is, I bet the
tracepoint was triggered when rcu wasn't watching.
-- Steve
> >
> > Thanks,
> > Philipp
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-09-02 19:38 ` Steven Rostedt
@ 2015-09-02 22:10 ` Philipp Schrader
2015-09-02 23:07 ` Paul E. McKenney
0 siblings, 1 reply; 13+ messages in thread
From: Philipp Schrader @ 2015-09-02 22:10 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Thomas Gleixner, linux-rt-users, Paul E. McKenney
On Wed, Sep 2, 2015 at 12:38 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 1 Sep 2015 17:35:23 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
>
>> On Mon, 31 Aug 2015, Philipp Schrader wrote:
>> > rcu_dereference_check() usage!
>> > [ 0.055093]
>> > [ 0.055093] other info that might help us debug this:
>> > [ 0.055093]
>> > [ 0.055097]
>> > [ 0.055097] RCU used illegally from idle CPU!
>> > [ 0.055097] rcu_scheduler_active = 1, debug_locks = 1
>> > [ 0.055100] RCU used illegally from extended quiescent state!
>> > [ 0.055104] no locks held by swapper/0/0.
>> > [ 0.055106]
>> > [ 0.055106] stack backtrace:
>> > [ 0.055112] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.6+ #2
>> > [ 0.055116] Hardware name: Generic DRA74X (Flattened Device Tree)
>> > [ 0.055130] [<c00196b8>] (unwind_backtrace) from [<c001515c>]
>> > (show_stack+0x20/0x24)
>> > [ 0.055146] [<c001515c>] (show_stack) from [<c07bc408>]
>> > (dump_stack+0x84/0xa0)
>> > [ 0.055160] [<c07bc408>] (dump_stack) from [<c009bc38>]
>> > (lockdep_rcu_suspicious+0xb0/0x110)
>> > [ 0.055172] [<c009bc38>] (lockdep_rcu_suspicious) from [<c01246c4>]
>> > (time_hardirqs_off+0x2b8/0x3c8)
>> > [ 0.055184] [<c01246c4>] (time_hardirqs_off) from [<c009a218>]
>> > (trace_hardirqs_off_caller+0x2c/0xf4)
>> > [ 0.055194] [<c009a218>] (trace_hardirqs_off_caller) from
>> > [<c009a2f4>] (trace_hardirqs_off+0x14/0x18)
>> > [ 0.055204] [<c009a2f4>] (trace_hardirqs_off) from [<c00c7ecc>]
>> > (rcu_idle_enter+0x78/0xcc)
>> > [ 0.055213] [<c00c7ecc>] (rcu_idle_enter) from [<c0093eb0>]
>> > (cpu_startup_entry+0x190/0x518)
>> > [ 0.055222] [<c0093eb0>] (cpu_startup_entry) from [<c07b95b4>]
>> > (rest_init+0x13c/0x17c)
>> > [ 0.055231] [<c07b95b4>] (rest_init) from [<c0b32c74>]
>> > (start_kernel+0x320/0x380)
>> > [ 0.055238] [<c0b32c74>] (start_kernel) from [<8000807c>] (0x8000807c)
>> >
>> > I'm not sure how to debug this; I'm still reading up on RCUs. Pretty
>> > nifty ideas.
>> >
>> > Looking at include/trace/events/hist.h it appears line 31 is the end
>> > of a TRACE_EVENT macro usage.
>> > Does that mean the macro is using RCU improperly somehow?
>
> I think this needs to be a trace_*_rcu_idle() call. That is, I bet the
> tracepoint was triggered when rcu wasn't watching.
Thank you for your reply Steve.
I've got the following patch now that makes the splat disappear:
diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
index aaade2e..d0e1d0e 100644
--- a/kernel/trace/trace_irqsoff.c
+++ b/kernel/trace/trace_irqsoff.c
@@ -450,7 +450,7 @@ EXPORT_SYMBOL_GPL(stop_critical_timings);
#ifdef CONFIG_PROVE_LOCKING
void time_hardirqs_on(unsigned long a0, unsigned long a1)
{
- trace_preemptirqsoff_hist(IRQS_ON, 0);
+ trace_preemptirqsoff_hist_rcuidle(IRQS_ON, 0);
if (!preempt_trace() && irq_trace())
stop_critical_timing(a0, a1);
}
@@ -459,7 +459,7 @@ void time_hardirqs_off(unsigned long a0, unsigned long a1)
{
if (!preempt_trace() && irq_trace())
start_critical_timing(a0, a1);
- trace_preemptirqsoff_hist(IRQS_OFF, 1);
+ trace_preemptirqsoff_hist_rcuidle(IRQS_OFF, 1);
}
#else /* !CONFIG_PROVE_LOCKING */
Does that look reasonable?
Or could this cause a problem down the road?
Still reading up on RCUs and how they work.
Thanks!
Philipp
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-09-02 22:10 ` Philipp Schrader
@ 2015-09-02 23:07 ` Paul E. McKenney
2015-09-03 16:53 ` Steven Rostedt
2015-09-03 16:55 ` Philipp Schrader
0 siblings, 2 replies; 13+ messages in thread
From: Paul E. McKenney @ 2015-09-02 23:07 UTC (permalink / raw)
To: Philipp Schrader; +Cc: Steven Rostedt, Thomas Gleixner, linux-rt-users
On Wed, Sep 02, 2015 at 03:10:04PM -0700, Philipp Schrader wrote:
> On Wed, Sep 2, 2015 at 12:38 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Tue, 1 Sep 2015 17:35:23 +0200 (CEST)
> > Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> >> On Mon, 31 Aug 2015, Philipp Schrader wrote:
>
> >> > rcu_dereference_check() usage!
> >> > [ 0.055093]
> >> > [ 0.055093] other info that might help us debug this:
> >> > [ 0.055093]
> >> > [ 0.055097]
> >> > [ 0.055097] RCU used illegally from idle CPU!
> >> > [ 0.055097] rcu_scheduler_active = 1, debug_locks = 1
> >> > [ 0.055100] RCU used illegally from extended quiescent state!
> >> > [ 0.055104] no locks held by swapper/0/0.
> >> > [ 0.055106]
> >> > [ 0.055106] stack backtrace:
> >> > [ 0.055112] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.6+ #2
> >> > [ 0.055116] Hardware name: Generic DRA74X (Flattened Device Tree)
> >> > [ 0.055130] [<c00196b8>] (unwind_backtrace) from [<c001515c>]
> >> > (show_stack+0x20/0x24)
> >> > [ 0.055146] [<c001515c>] (show_stack) from [<c07bc408>]
> >> > (dump_stack+0x84/0xa0)
> >> > [ 0.055160] [<c07bc408>] (dump_stack) from [<c009bc38>]
> >> > (lockdep_rcu_suspicious+0xb0/0x110)
> >> > [ 0.055172] [<c009bc38>] (lockdep_rcu_suspicious) from [<c01246c4>]
> >> > (time_hardirqs_off+0x2b8/0x3c8)
> >> > [ 0.055184] [<c01246c4>] (time_hardirqs_off) from [<c009a218>]
> >> > (trace_hardirqs_off_caller+0x2c/0xf4)
> >> > [ 0.055194] [<c009a218>] (trace_hardirqs_off_caller) from
> >> > [<c009a2f4>] (trace_hardirqs_off+0x14/0x18)
> >> > [ 0.055204] [<c009a2f4>] (trace_hardirqs_off) from [<c00c7ecc>]
> >> > (rcu_idle_enter+0x78/0xcc)
> >> > [ 0.055213] [<c00c7ecc>] (rcu_idle_enter) from [<c0093eb0>]
> >> > (cpu_startup_entry+0x190/0x518)
> >> > [ 0.055222] [<c0093eb0>] (cpu_startup_entry) from [<c07b95b4>]
> >> > (rest_init+0x13c/0x17c)
> >> > [ 0.055231] [<c07b95b4>] (rest_init) from [<c0b32c74>]
> >> > (start_kernel+0x320/0x380)
> >> > [ 0.055238] [<c0b32c74>] (start_kernel) from [<8000807c>] (0x8000807c)
> >> >
> >> > I'm not sure how to debug this; I'm still reading up on RCUs. Pretty
> >> > nifty ideas.
> >> >
> >> > Looking at include/trace/events/hist.h it appears line 31 is the end
> >> > of a TRACE_EVENT macro usage.
> >> > Does that mean the macro is using RCU improperly somehow?
> >
> > I think this needs to be a trace_*_rcu_idle() call. That is, I bet the
> > tracepoint was triggered when rcu wasn't watching.
>
> Thank you for your reply Steve.
> I've got the following patch now that makes the splat disappear:
>
> diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
> index aaade2e..d0e1d0e 100644
> --- a/kernel/trace/trace_irqsoff.c
> +++ b/kernel/trace/trace_irqsoff.c
> @@ -450,7 +450,7 @@ EXPORT_SYMBOL_GPL(stop_critical_timings);
> #ifdef CONFIG_PROVE_LOCKING
> void time_hardirqs_on(unsigned long a0, unsigned long a1)
> {
> - trace_preemptirqsoff_hist(IRQS_ON, 0);
> + trace_preemptirqsoff_hist_rcuidle(IRQS_ON, 0);
> if (!preempt_trace() && irq_trace())
> stop_critical_timing(a0, a1);
> }
> @@ -459,7 +459,7 @@ void time_hardirqs_off(unsigned long a0, unsigned long a1)
> {
> if (!preempt_trace() && irq_trace())
> start_critical_timing(a0, a1);
> - trace_preemptirqsoff_hist(IRQS_OFF, 1);
> + trace_preemptirqsoff_hist_rcuidle(IRQS_OFF, 1);
> }
>
> #else /* !CONFIG_PROVE_LOCKING */
>
> Does that look reasonable?
> Or could this cause a problem down the road?
Looks good to me!
> Still reading up on RCUs and how they work.
Me too. ;-)
Thanx, Paul
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-09-02 23:07 ` Paul E. McKenney
@ 2015-09-03 16:53 ` Steven Rostedt
2015-09-03 21:39 ` Paul E. McKenney
2015-09-03 16:55 ` Philipp Schrader
1 sibling, 1 reply; 13+ messages in thread
From: Steven Rostedt @ 2015-09-03 16:53 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: Philipp Schrader, Thomas Gleixner, linux-rt-users
On Wed, 2 Sep 2015 16:07:29 -0700
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > Does that look reasonable?
> > Or could this cause a problem down the road?
>
> Looks good to me!
If it looks good to Paul, it looks good to me :-)
>
> > Still reading up on RCUs and how they work.
>
> Me too. ;-)
Who are you reading up on RCUs from?
-- Steve
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-09-02 23:07 ` Paul E. McKenney
2015-09-03 16:53 ` Steven Rostedt
@ 2015-09-03 16:55 ` Philipp Schrader
2015-09-03 17:12 ` Steven Rostedt
2015-12-11 16:32 ` Sebastian Andrzej Siewior
1 sibling, 2 replies; 13+ messages in thread
From: Philipp Schrader @ 2015-09-03 16:55 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: Steven Rostedt, Thomas Gleixner, linux-rt-users
On Wed, Sep 02, 2015 at 04:07:29PM -0700, Paul E. McKenney wrote:
> On Wed, Sep 02, 2015 at 03:10:04PM -0700, Philipp Schrader wrote:
> > I've got the following patch now that makes the splat disappear:
> >
> > diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
> > index aaade2e..d0e1d0e 100644
> > --- a/kernel/trace/trace_irqsoff.c
> > +++ b/kernel/trace/trace_irqsoff.c
> > @@ -450,7 +450,7 @@ EXPORT_SYMBOL_GPL(stop_critical_timings);
> > #ifdef CONFIG_PROVE_LOCKING
> > void time_hardirqs_on(unsigned long a0, unsigned long a1)
> > {
> > - trace_preemptirqsoff_hist(IRQS_ON, 0);
> > + trace_preemptirqsoff_hist_rcuidle(IRQS_ON, 0);
> > if (!preempt_trace() && irq_trace())
> > stop_critical_timing(a0, a1);
> > }
> > @@ -459,7 +459,7 @@ void time_hardirqs_off(unsigned long a0, unsigned long a1)
> > {
> > if (!preempt_trace() && irq_trace())
> > start_critical_timing(a0, a1);
> > - trace_preemptirqsoff_hist(IRQS_OFF, 1);
> > + trace_preemptirqsoff_hist_rcuidle(IRQS_OFF, 1);
> > }
> >
> > #else /* !CONFIG_PROVE_LOCKING */
> >
> > Does that look reasonable?
> > Or could this cause a problem down the road?
>
> Looks good to me!
Should I submit a patch for this or is this just a fix for my particular kernel
configuration? I don't yet understand the code well enough to know the answer.
Thanks,
Philipp
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-09-03 16:55 ` Philipp Schrader
@ 2015-09-03 17:12 ` Steven Rostedt
2015-12-11 16:32 ` Sebastian Andrzej Siewior
1 sibling, 0 replies; 13+ messages in thread
From: Steven Rostedt @ 2015-09-03 17:12 UTC (permalink / raw)
To: Philipp Schrader; +Cc: Paul E. McKenney, Thomas Gleixner, linux-rt-users
On Thu, 3 Sep 2015 09:55:46 -0700
Philipp Schrader <philipp@peloton-tech.com> wrote:
> Should I submit a patch for this or is this just a fix for my particular kernel
> configuration? I don't yet understand the code well enough to know the answer.
It should be added to the mainline -rt patches.
-- Steve
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-09-03 16:53 ` Steven Rostedt
@ 2015-09-03 21:39 ` Paul E. McKenney
0 siblings, 0 replies; 13+ messages in thread
From: Paul E. McKenney @ 2015-09-03 21:39 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Philipp Schrader, Thomas Gleixner, linux-rt-users
On Thu, Sep 03, 2015 at 12:53:45PM -0400, Steven Rostedt wrote:
> On Wed, 2 Sep 2015 16:07:29 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
>
> > > Does that look reasonable?
> > > Or could this cause a problem down the road?
> >
> > Looks good to me!
>
> If it looks good to Paul, it looks good to me :-)
>
> >
> > > Still reading up on RCUs and how they work.
> >
> > Me too. ;-)
>
> Who are you reading up on RCUs from?
Splats, oopses, and hangs when I try modifying it. And bug reports
from people using it. ;-)
Thanx, Paul
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-09-03 16:55 ` Philipp Schrader
2015-09-03 17:12 ` Steven Rostedt
@ 2015-12-11 16:32 ` Sebastian Andrzej Siewior
2015-12-11 16:46 ` Philipp Schrader
1 sibling, 1 reply; 13+ messages in thread
From: Sebastian Andrzej Siewior @ 2015-12-11 16:32 UTC (permalink / raw)
To: Philipp Schrader
Cc: Paul E. McKenney, Steven Rostedt, Thomas Gleixner, linux-rt-users
* Philipp Schrader | 2015-09-03 09:55:46 [-0700]:
>> > Does that look reasonable?
>> > Or could this cause a problem down the road?
>>
>> Looks good to me!
>
>Should I submit a patch for this or is this just a fix for my particular kernel
>configuration? I don't yet understand the code well enough to know the answer.
Did someone in the meantime sent a patch? It does not look so.
If this patch gets re-sent witch a changelog and gets acked by Paul/Steven I
don't see a problem why I should not include it.
>Thanks,
>Philipp
Sebastian
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-12-11 16:32 ` Sebastian Andrzej Siewior
@ 2015-12-11 16:46 ` Philipp Schrader
2015-12-11 16:53 ` Paul E. McKenney
0 siblings, 1 reply; 13+ messages in thread
From: Philipp Schrader @ 2015-12-11 16:46 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Paul E. McKenney, Steven Rostedt, Thomas Gleixner, linux-rt-users
On Fri, Dec 11, 2015 at 8:32 AM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> Did someone in the meantime sent a patch? It does not look so.
> If this patch gets re-sent witch a changelog and gets acked by Paul/Steven I
> don't see a problem why I should not include it.
>
> Sebastian
I sent out a patch here:
http://lkml.iu.edu/hypermail/linux/kernel/1509.0/02788.html
Though I never received a response.
Shall I re-send it?
Philipp
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-12-11 16:46 ` Philipp Schrader
@ 2015-12-11 16:53 ` Paul E. McKenney
2015-12-11 16:59 ` Philipp Schrader
0 siblings, 1 reply; 13+ messages in thread
From: Paul E. McKenney @ 2015-12-11 16:53 UTC (permalink / raw)
To: Philipp Schrader
Cc: Sebastian Andrzej Siewior, Steven Rostedt, Thomas Gleixner,
linux-rt-users
On Fri, Dec 11, 2015 at 08:46:13AM -0800, Philipp Schrader wrote:
> On Fri, Dec 11, 2015 at 8:32 AM, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
> > Did someone in the meantime sent a patch? It does not look so.
> > If this patch gets re-sent witch a changelog and gets acked by Paul/Steven I
> > don't see a problem why I should not include it.
> >
> > Sebastian
>
> I sent out a patch here:
> http://lkml.iu.edu/hypermail/linux/kernel/1509.0/02788.html
> Though I never received a response.
I replied with "Looks good to me!"
> Shall I re-send it?
If Steven is OK with the patch, you can use:
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Thanx, Paul
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RCU splat on boot from an idle CPU
2015-12-11 16:53 ` Paul E. McKenney
@ 2015-12-11 16:59 ` Philipp Schrader
0 siblings, 0 replies; 13+ messages in thread
From: Philipp Schrader @ 2015-12-11 16:59 UTC (permalink / raw)
To: Paul McKenney
Cc: Sebastian Andrzej Siewior, Steven Rostedt, Thomas Gleixner,
linux-rt-users
On Fri, Dec 11, 2015 at 8:53 AM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Fri, Dec 11, 2015 at 08:46:13AM -0800, Philipp Schrader wrote:
>> On Fri, Dec 11, 2015 at 8:32 AM, Sebastian Andrzej Siewior
>> <bigeasy@linutronix.de> wrote:
>> > Did someone in the meantime sent a patch? It does not look so.
>> > If this patch gets re-sent witch a changelog and gets acked by Paul/Steven I
>> > don't see a problem why I should not include it.
>> >
>> > Sebastian
>>
>> I sent out a patch here:
>> http://lkml.iu.edu/hypermail/linux/kernel/1509.0/02788.html
>> Though I never received a response.
>
> I replied with "Looks good to me!"
My apologies, I was thinking of a response to the e-mail I sent to
LKML. i did see your response on rt-users, sorry.
>
>> Shall I re-send it?
>
> If Steven is OK with the patch, you can use:
>
> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Ah, I will re-send the patch tonight then with the additional Acked-by.
> Thanx, Paul
>
Philipp
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-12-11 16:59 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-01 0:46 RCU splat on boot from an idle CPU Philipp Schrader
2015-09-01 15:35 ` Thomas Gleixner
2015-09-02 19:38 ` Steven Rostedt
2015-09-02 22:10 ` Philipp Schrader
2015-09-02 23:07 ` Paul E. McKenney
2015-09-03 16:53 ` Steven Rostedt
2015-09-03 21:39 ` Paul E. McKenney
2015-09-03 16:55 ` Philipp Schrader
2015-09-03 17:12 ` Steven Rostedt
2015-12-11 16:32 ` Sebastian Andrzej Siewior
2015-12-11 16:46 ` Philipp Schrader
2015-12-11 16:53 ` Paul E. McKenney
2015-12-11 16:59 ` Philipp Schrader
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.