[PATCH -rt] wrong usage of smp_processor_id()

[PATCH -rt] wrong usage of smp_processor_id()

[Daniel Walker]

Found this while debugging with Steve .. trace_hardirqs_on() isn't always 
called with interrupt off.

 BUG: using smp_processor_id() in preemptible [00000000] code: init/1

 caller is trace_hardirqs_on+0x16/0xe0
  [<c01054b1>] show_trace_log_lvl+0x21/0x50
  [<c0105c82>] show_trace+0x12/0x20
  [<c0105d56>] dump_stack+0x16/0x20
  [<c022c819>] debug_smp_processor_id+0xa9/0xb0
  [<c0152a76>] trace_hardirqs_on+0x16/0xe0
  [<c0103975>] do_notify_resume+0x115/0x7b0
  [<c01044f4>] work_notifysig+0x13/0x1b
  =======================
 ---------------------------
 | preempt count: 00000001 ]
 | 1-level deep critical section nesting:
 ----------------------------------------
 .. [<c022c7c3>] .... debug_smp_processor_id+0x53/0xb0
 .....[<c0152a76>] ..   ( <= trace_hardirqs_on+0x16/0xe0)


Signed-Off-By: Daniel Walker <dwalker@mvista.com>

---
 kernel/latency_trace.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.21/kernel/latency_trace.c
===================================================================
--- linux-2.6.21.orig/kernel/latency_trace.c
+++ linux-2.6.21/kernel/latency_trace.c
@@ -105,7 +105,7 @@ static inline int DEBUG_WARN_ON(int cond
 #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING
 # ifdef CONFIG_CRITICAL_PREEMPT_TIMING
    static DEFINE_PER_CPU(int, trace_cpu_idle);
-#  define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && preempt_count())
+#  define irqs_off_preempt_count() (preempt_count() && !__get_cpu_var(trace_cpu_idle))
 # else
 #  define irqs_off_preempt_count() 0
 # endif
-- 

-- 

Re: [PATCH -rt] wrong usage of smp_processor_id()

[Steven Rostedt]

Daniel Walker wrote:

> ---
>  kernel/latency_trace.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6.21/kernel/latency_trace.c
> ===================================================================
> --- linux-2.6.21.orig/kernel/latency_trace.c
> +++ linux-2.6.21/kernel/latency_trace.c
> @@ -105,7 +105,7 @@ static inline int DEBUG_WARN_ON(int cond
>  #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING
>  # ifdef CONFIG_CRITICAL_PREEMPT_TIMING
>     static DEFINE_PER_CPU(int, trace_cpu_idle);
> -#  define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && preempt_count())
> +#  define irqs_off_preempt_count() (preempt_count() && !__get_cpu_var(trace_cpu_idle))
>  # else
>  #  define irqs_off_preempt_count() 0
>  # endif

Ingo,

This is on top of one of my patches that I sent you (the cpu idle one). 
So it's not for the 2.6.21-rt1, but if you apply my patch, this needs to 
be added too.

Acked-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve

Re: [PATCH -rt] wrong usage of smp_processor_id()

[Daniel Walker]

On Thu, 2007-05-03 at 16:12 -0400, Steven Rostedt wrote:
> Daniel Walker wrote:
> 
> > ---
> >  kernel/latency_trace.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: linux-2.6.21/kernel/latency_trace.c
> > ===================================================================
> > --- linux-2.6.21.orig/kernel/latency_trace.c
> > +++ linux-2.6.21/kernel/latency_trace.c
> > @@ -105,7 +105,7 @@ static inline int DEBUG_WARN_ON(int cond
> >  #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING
> >  # ifdef CONFIG_CRITICAL_PREEMPT_TIMING
> >     static DEFINE_PER_CPU(int, trace_cpu_idle);
> > -#  define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && preempt_count())
> > +#  define irqs_off_preempt_count() (preempt_count() && !__get_cpu_var(trace_cpu_idle))
> >  # else
> >  #  define irqs_off_preempt_count() 0
> >  # endif
> 
> Ingo,
> 
> This is on top of one of my patches that I sent you (the cpu idle one). 
> So it's not for the 2.6.21-rt1, but if you apply my patch, this needs to 
> be added too.

Isn't it a generic problem? It doesn't look specific to your change
unless you made some changes to entry.S .

Daniel

Re: [PATCH -rt] wrong usage of smp_processor_id()

[Steven Rostedt]

Daniel Walker wrote:

>>> Index: linux-2.6.21/kernel/latency_trace.c
>>> ===================================================================
>>> --- linux-2.6.21.orig/kernel/latency_trace.c
>>> +++ linux-2.6.21/kernel/latency_trace.c
>>> @@ -105,7 +105,7 @@ static inline int DEBUG_WARN_ON(int cond
>>>  #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING
>>>  # ifdef CONFIG_CRITICAL_PREEMPT_TIMING
>>>     static DEFINE_PER_CPU(int, trace_cpu_idle);
>>> -#  define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && preempt_count())
>>> +#  define irqs_off_preempt_count() (preempt_count() && !__get_cpu_var(trace_cpu_idle))
>>>  # else
>>>  #  define irqs_off_preempt_count() 0
>>>  # endif


> Isn't it a generic problem? It doesn't look specific to your change
> unless you made some changes to entry.S .
> 

See: http://lkml.org/lkml/2007/4/23/183

Specifically:


  #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING
  # ifdef CONFIG_CRITICAL_PREEMPT_TIMING
-#  define irqs_off_preempt_count() preempt_count()
+   static DEFINE_PER_CPU(int, trace_cpu_idle);
+#  define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && 
preempt_count())
  # else
  #  define irqs_off_preempt_count() 0
  # endif
@@ -2153,6 +2154,20 @@ void notrace unmask_preempt_count(unsign
  }
  EXPORT_SYMBOL(unmask_preempt_count);


-- Steve

Re: [PATCH -rt] wrong usage of smp_processor_id()

[Daniel Walker]

On Thu, 2007-05-03 at 16:31 -0400, Steven Rostedt wrote:
> Daniel Walker wrote:
> 
> >>> Index: linux-2.6.21/kernel/latency_trace.c
> >>> ===================================================================
> >>> --- linux-2.6.21.orig/kernel/latency_trace.c
> >>> +++ linux-2.6.21/kernel/latency_trace.c
> >>> @@ -105,7 +105,7 @@ static inline int DEBUG_WARN_ON(int cond
> >>>  #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING
> >>>  # ifdef CONFIG_CRITICAL_PREEMPT_TIMING
> >>>     static DEFINE_PER_CPU(int, trace_cpu_idle);
> >>> -#  define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && preempt_count())
> >>> +#  define irqs_off_preempt_count() (preempt_count() && !__get_cpu_var(trace_cpu_idle))
> >>>  # else
> >>>  #  define irqs_off_preempt_count() 0
> >>>  # endif
> 
> 
> > Isn't it a generic problem? It doesn't look specific to your change
> > unless you made some changes to entry.S .
> > 
> 
> See: http://lkml.org/lkml/2007/4/23/183
> 


Ahh, well safe bet I think.

Daniel