diff options
author | Ralf Baechle <ralf@linux-mips.org> | 2008-02-11 14:51:40 +0000 |
---|---|---|
committer | Ralf Baechle <ralf@linux-mips.org> | 2008-02-19 17:01:31 +0000 |
commit | 2eaa7ec286db54cc1a864565ed9367966743bcbd (patch) | |
tree | b764cafe754f065ea47e93c2e568836f76f3d339 /arch/mips/gt64120/wrppmc | |
parent | eaf7943cc53d9688aa10267a226165356e956ec5 (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/gt64120/wrppmc')
0 files changed, 0 insertions, 0 deletions