Re: [PATCH] perf: Use raw_smp_processor_id insted of smp_processor_id

[Stephen Boyd <sboyd@codeaurora.org>]

On 09/12/12 05:05, Russell King - ARM Linux wrote:
> NAK.  Using a different function which doesn't have the warning isn't a
> subsitute for fixing the problem properly.  What you're doing is papering
> over the bug, making the warning go away without properly understanding
> the problem.
>
> The warning is there because something is being done wrong.  What that is
> is exactly what is being said in the warning message.  You're getting a
> CPU number in a context where preemptions can occur - and therefore the
> CPU that you're running on can change.
>
> Think about this sequence:
>
> 	- cpu = smp_processor_id(); /* returns 0 */
> 	- you are preempted
> 	- you resume on CPU 1
> 	- trace_clock_disable(clk->name, 0, 0);
>
> If trace_clock_disable() uses the CPU number to access per-CPU data
> without locking, that's going to cause corruption.
>
> Please, if you're going to fix a warning, analyse it properly first and
> don't just search for a function which appears to give you the same
> functionality but without the warning message.

Is anyone actually using the CPU field in this tracepoint? I don't see
any usecase for it except for the case where you have a percpu clock,
but even then I imagine the name of the clock would be different
depending on which CPU it corresponds to. So why can't we just remove
the CPU field from the tracepoint?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation