diff options
author | George G. Davis <davis_g@mvista.com> | 2006-09-02 18:43:20 +0100 |
---|---|---|
committer | Russell King <rmk+kernel@arm.linux.org.uk> | 2006-09-02 18:43:20 +0100 |
commit | a188ad2bc7dbfa16ccdcaa8d43ade185b969baff (patch) | |
tree | 7938fff8dded204e92bd7c3149875abb8d7060aa /arch/cris | |
parent | 57bcdafcb1e0782e7ae13471d9223c69e3a6cba2 (diff) |
[ARM] 3762/1: Fix ptrace cache coherency bug for ARM1136 VIPT nonaliasing Harvard caches
Patch from George G. Davis
Resolve ARM1136 VIPT non-aliasing cache coherency issues observed when
using ptrace to set breakpoints and cleanup copy_{to,from}_user_page()
while we're here as requested by Russell King because "it's also far
too heavy on non-v6 CPUs".
NOTES:
1. Only access_process_vm() calls copy_{to,from}_user_page().
2. access_process_vm() calls get_user_pages() to pin down the "page".
3. get_user_pages() calls flush_dcache_page(page) which ensures cache
coherency between kernel and userspace mappings of "page". However
flush_dcache_page(page) may not invalidate I-Cache over this range
for all cases, specifically, I-Cache is not invalidated for the VIPT
non-aliasing case. So memory is consistent between kernel and user
space mappings of "page" but I-Cache may still be hot over this
range. IOW, we don't have to worry about flush_cache_page() before
memcpy().
4. Now, for the copy_to_user_page() case, after memcpy(), we must flush
the caches so memory is consistent with kernel cache entries and
invalidate the I-Cache if this mm region is executable. We don't
need to do anything after memcpy() for the copy_from_user_page()
case since kernel cache entries will be invalidated via the same
process above if we access "page" again. The flush_ptrace_access()
function (borrowed from SPARC64 implementation) is added to handle
cache flushing after memcpy() for the copy_to_user_page() case.
Signed-off-by: George G. Davis <gdavis@mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'arch/cris')
0 files changed, 0 insertions, 0 deletions