aboutsummaryrefslogtreecommitdiffstats
path: root/scripts
diff options
context:
space:
mode:
authorWill Deacon <will.deacon@arm.com>2013-06-05 11:20:33 +0100
committerRussell King <rmk+kernel@arm.linux.org.uk>2013-06-05 23:35:56 +0100
commit509eb76ebf9771abc9fe51859382df2571f11447 (patch)
treea5745368df4dbe458dc4de5fa63778e9b8cda2cc /scripts
parentARM: 7750/1: update legacy CPU ID in decompressor cache support jump table (diff)
downloadlinux-dev-509eb76ebf9771abc9fe51859382df2571f11447.tar.xz
linux-dev-509eb76ebf9771abc9fe51859382df2571f11447.zip
ARM: 7747/1: pcpu: ensure __my_cpu_offset cannot be re-ordered across barrier()
__my_cpu_offset is non-volatile, since we want its value to be cached when we access several per-cpu variables in a row with preemption disabled. This means that we rely on preempt_{en,dis}able to hazard with the operation via the barrier() macro, so that we can't end up migrating CPUs without reloading the per-cpu offset. Unfortunately, GCC doesn't treat a "memory" clobber on a non-volatile asm block as a side-effect, and will happily re-order it before other memory clobbers (including those in prempt_disable()) and cache the value. This has been observed to break the cmpxchg logic in the slub allocator, leading to livelock in kmem_cache_alloc in mainline kernels. This patch adds a dummy memory input operand to __my_cpu_offset, forcing it to be ordered with respect to the barrier() macro. Cc: <stable@vger.kernel.org> Cc: Rob Herring <rob.herring@calxeda.com> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'scripts')
0 files changed, 0 insertions, 0 deletions