aboutsummaryrefslogtreecommitdiff
path: root/arch/mips/kernel/irq-rm7000.c
diff options
context:
space:
mode:
authorRalf Baechle <ralf@linux-mips.org>2008-02-11 14:51:40 +0000
committerRalf Baechle <ralf@linux-mips.org>2008-02-19 17:01:31 +0000
commit2eaa7ec286db54cc1a864565ed9367966743bcbd (patch)
treeb764cafe754f065ea47e93c2e568836f76f3d339 /arch/mips/kernel/irq-rm7000.c
parenteaf7943cc53d9688aa10267a226165356e956ec5 (diff)
[MIPS] Handle I-cache coherency in flush_cache_range()
So far flush_cache_range() did't consider the I-cache largely because it did rarely ever matter to real world code. This was working primarily because normally code and data are don't share the same pages - with the exception of MIPS16 code which uses address constants embedded between the code. The following sequence of events may break the code: o MIPS16 executable being loaded o dynamic linker relocates the address constants embedded into the code: o Uses mprotect(2) to make code pages PROT_READ|PROT_WRITE o Performs the actual relocations by writing to the pages which likely are COW. Because no PROT_EXEC is set I-cache coherence will not be considered. o Uses mprotect(2) to switch code pages back to PROT_READ|PROT_EXEC. This results in a call to flush_cache_range() which also does not consider I-caches. o => executing the page just having been relocated may now result in the I-cache getting refilled with stale data from memory. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Diffstat (limited to 'arch/mips/kernel/irq-rm7000.c')
0 files changed, 0 insertions, 0 deletions