Thread (4 messages) flat view 4 messages, 3 authors, 2012-09-12
STALE5097d

[PATCH] perf: Use raw_smp_processor_id insted of smp_processor_id

From: Stephen Boyd <hidden>
Date: 2012-09-12 18:44:29
Also in: linux-omap

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help