summaryrefslogtreecommitdiffstats
path: root/arch/sparc/Makefile
diff options
context:
space:
mode:
authorPaul Mackerras <paulus@samba.org>2009-08-14 15:39:10 +1000
committerIngo Molnar <mingo@elte.hu>2009-08-17 11:38:13 +0200
commite1ac3614ff606ae03677f47459113f98a19af63c (patch)
treee2317686271461fad79cf88280f8a2eadf5bb88d /arch/sparc/Makefile
parent2932cffc89e9a1476b28a59896fa4f81e0d4f131 (diff)
downloadlinux-e1ac3614ff606ae03677f47459113f98a19af63c.tar.gz
linux-e1ac3614ff606ae03677f47459113f98a19af63c.tar.bz2
linux-e1ac3614ff606ae03677f47459113f98a19af63c.zip
perf_counter: Check task on counter read IPI
In general, code in perf_counter.c that is called through an IPI checks, for per-task counters, that the counter's task is still the current task. This is to handle the race condition where the cpu switches from the task we want to another task in the interval between sending the IPI and the IPI arriving and being handled on the target CPU. For some reason, __perf_counter_read is missing this check, yet there is no reason why the race condition can't occur. This adds a check that the current task is the one we want. If it isn't, we just return. In that case the counter->count value should be up to date, since it will have been updated when the counter was scheduled out, which must have happened since the IPI was sent. I don't have an example of an actual failure due to this race, but it seems obvious that it could occur and we need to guard against it. Signed-off-by: Paul Mackerras <paulus@samba.org> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <19076.63614.277861.368125@drongo.ozlabs.ibm.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'arch/sparc/Makefile')
0 files changed, 0 insertions, 0 deletions