* 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-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-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: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 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).