forked from Minki/linux
2eaa7ec286
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>
|
||
|---|---|---|
| .. | ||
| c-r3k.c | ||
| c-r4k.c | ||
| c-tx39.c | ||
| cache.c | ||
| cerr-sb1.c | ||
| cex-gen.S | ||
| cex-sb1.S | ||
| dma-default.c | ||
| extable.c | ||
| fault.c | ||
| highmem.c | ||
| init.c | ||
| ioremap.c | ||
| Makefile | ||
| pg-r4k.c | ||
| pg-sb1.c | ||
| pgtable-32.c | ||
| pgtable-64.c | ||
| pgtable.c | ||
| sc-ip22.c | ||
| sc-mips.c | ||
| sc-r5k.c | ||
| sc-rm7k.c | ||
| tlb-r3k.c | ||
| tlb-r4k.c | ||
| tlb-r8k.c | ||
| tlbex-fault.S | ||
| tlbex.c | ||
| uasm.c | ||
| uasm.h | ||