aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorPeter Zijlstra <[email protected]>2020-10-05 09:56:57 +0200
committerIngo Molnar <[email protected]>2020-10-09 08:54:00 +0200
commitbaffd723e44dc3d7f84f0b8f1fe1ece00ddd2710 (patch)
tree3e39abc0cc9a2ddee427e03a09d97b8b5bf61828 /tools/perf/scripts/python/export-to-postgresql.py
parent4d004099a668c41522242aa146a38cc4eb59cb1e (diff)
lockdep: Revert "lockdep: Use raw_cpu_*() for per-cpu variables"
The thinking in commit: fddf9055a60d ("lockdep: Use raw_cpu_*() for per-cpu variables") is flawed. While it is true that when we're migratable both CPUs will have a 0 value, it doesn't hold that when we do get migrated in the middle of a raw_cpu_op(), the old CPU will still have 0 by the time we get around to reading it on the new CPU. Luckily, the reason for that commit (s390 using preempt_disable() instead of preempt_disable_notrace() in their percpu code), has since been fixed by commit: 1196f12a2c96 ("s390: don't trace preemption in percpu macros") An audit of arch/*/include/asm/percpu*.h shows there are no other architectures affected by this particular issue. Fixes: fddf9055a60d ("lockdep: Use raw_cpu_*() for per-cpu variables") Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions