- 25 9月, 2006 1 次提交
-
-
由 George G. Davis 提交于
Fix thinko in the flush_ptrace_access() "if (expr)" for the ARM VIPT non-aliasing cache case. We only need to flush cache when VM_EXEC is set in vma->vm_flags but "if (expr) always evaluates to true on UP systems for the ARM VIPT non-aliasing cache case. Signed-off-by: NGeorge G. Davis <gdavis@mvista.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 20 9月, 2006 1 次提交
-
-
由 Russell King 提交于
Move top_pmd into arch/arm/mm/mm.h - nothing outside arch/arm/mm references it. Move the repeated definition of TOP_PTE into mm/mm.h, as well as a few function prototypes. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 03 9月, 2006 1 次提交
-
-
由 George G. Davis 提交于
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: NGeorge G. Davis <gdavis@mvista.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 11 3月, 2006 1 次提交
-
-
由 Catalin Marinas 提交于
Patch from Catalin Marinas ARM1136 erratum 371025 (category 2) specifies that, under rare conditions, an invalidate I-cache by MVA (line or range) operation can fail to invalidate a cache line. The recommended workaround is to either invalidate the entire I-cache or invalidate the range by set/way rather than MVA. Note that for a 16K cache size, invalidating a 4K page by set/way is equivalent to invalidating the entire I-cache. Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 01 12月, 2005 1 次提交
-
-
由 Russell King 提交于
Lazy flush_dcache_page() causes userspace instability on SMP platforms, so disable it for now. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 30 9月, 2005 1 次提交
-
-
由 Catalin Marinas 提交于
Patch from Catalin Marinas When CONFIG_CPU_CACHE_VIPT is defined, the flush_pfn_alias() function is implicitely declared and it later conflicts with its actual definition. This patch moves the function definition to the beginning of the file. Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 08 9月, 2005 1 次提交
-
-
由 Russell King 提交于
This adds the necessary changes to ensure that we flush the caches correctly with aliasing VIPT caches. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 20 6月, 2005 1 次提交
-
-
由 Russell King 提交于
flush_dcache_page() did nothing for these caches, but since they suffer from I/D cache coherency issues, we need to ensure that data is written back to RAM. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 11 5月, 2005 1 次提交
-
-
由 Russell King 提交于
Add cache flushing support for aliased V6 caches to flush_dcache_page. Signed-off-by: NRussell King <rmk@arm.linux.org.uk>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-