diff options
| author | Peter Zijlstra <peterz@infradead.org> | 2020-10-05 09:56:57 +0200 |
|---|---|---|
| committer | Ingo Molnar <mingo@kernel.org> | 2020-10-09 08:54:00 +0200 |
| commit | baffd723e44dc3d7f84f0b8f1fe1ece00ddd2710 (patch) | |
| tree | 3e39abc0cc9a2ddee427e03a09d97b8b5bf61828 /mm/percpu.c | |
| parent | 4d004099a668c41522242aa146a38cc4eb59cb1e (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) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lkml.kernel.org/r/20201005095958.GJ2651@hirez.programming.kicks-ass.net
Diffstat (limited to 'mm/percpu.c')
0 files changed, 0 insertions, 0 deletions