-
由 Ralf Baechle 提交于
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: NRalf Baechle <ralf@linux-mips.org>
2eaa7ec2