MIPS: c-r4k: Use SMP calls for CM indexed cache ops
authorJames Hogan <james.hogan@imgtec.com>
Wed, 13 Jul 2016 13:12:56 +0000 (14:12 +0100)
committerRalf Baechle <ralf@linux-mips.org>
Fri, 29 Jul 2016 08:19:30 +0000 (10:19 +0200)
commit11f769039e1d10652bb45e83ecaad18a8681d5e5
treee024eb19a947297071834afdf4395b488ba33f3b
parentf70ddc07b637e8859dbdc9073fa80c95e218750d
MIPS: c-r4k: Use SMP calls for CM indexed cache ops

The MIPS Coherence Manager (CM) can propagate address-based ("hit")
cache operations to other cores in the coherent system, alleviating
software of the need to use SMP calls, however indexed cache operations
are not propagated by hardware since doing so makes no sense for
separate caches.

Update r4k_op_needs_ipi() to report that only hit cache operations are
globalized by the CM, requiring indexed cache operations to be
globalized by software via an SMP call.

r4k_on_each_cpu() previously had a special case for CONFIG_MIPS_MT_SMP,
intended to avoid the SMP calls when the only other CPUs in the system
were other VPEs in the same core, and hence sharing the same caches.
This was changed by commit cccf34e9411c ("MIPS: c-r4k: Fix cache
flushing for MT cores") to apparently handle multi-core multi-VPE
systems, but it focussed mainly on hit cache ops, so the SMP calls were
still disabled entirely for CM systems.

This doesn't normally cause problems, but tests can be written to hit
these corner cases by using multiple threads, or changing task
affinities to force the process to migrate cores. For example the
failure of mprotect RW->RX to globally sync icaches (via
flush_cache_range) can be detected by modifying and mprotecting a code
page on one core, and migrating to a different core to execute from it.

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13807/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
arch/mips/mm/c-r4k.c
This page took 0.024388 seconds and 5 git commands to generate.