user/sven/linux.git/include/asm-sparc/cacheflush.h, branch v2.6.16.45

[MM]: Add 'pfn' arg to flush_cache_page().

2005-02-25T08:36:06Z

Based almost entirely upon a patch by Russell King. Signed-off-by: David S. Miller

[PATCH] fix problematic flush_cache_page in kernel/ptrace.c

2004-09-23T01:08:58Z

At present, flush_cache_page() is used to handle the case where we unmap a page or alter the page permissions on the target page with one exception - access_process_vm(). Based upon the former, the decision to implement this function is: do we need to flush the cache when we unmap or change the mapping permissions? However, kernel/ptrace.c: access_process_vm() also includes into this: or we need to ensure cache coherency between the kernel and user space mapping of this page. I argue that the use of flush_cache_page() here in the generic code is wrong, and if an architecture wishes to use it for this purpose, it should do so within it's architecture private implementation of copy_to_user_page() and copy_from_user_page(). So this patch removes the flush_cache_page() from kernel/ptrace.c, adding it to the arch-specific copy_{to,from}_user_page() where flush_cache_page is non-empty. Signed-off-by: Linus Torvalds

[PATCH] rmap 23 empty flush_dcache_mmap_lock

2004-05-22T15:07:38Z

From: Hugh Dickins Most architectures (like i386) do nothing in flush_dcache_page, or don't scan i_mmap in flush_dcache_page, so don't need flush_dcache_mmap_lock to do anything: define it and flush_dcache_mmap_unlock away. Noticed arm26, cris, h8300 still defining flush_page_to_ram: delete it again.

[PATCH] memory writeback/invalidation fixes

2003-10-01T17:57:58Z

From: "David S. Miller" This attempts to take care of 2 of the MM todos I had on my backlog: 1) Zap the stupid flush_cache_all() thing with more meaningful interfaces. 2) Resolve the ptrace user page access issues, first stage. The "first stage" mentioned for #2 is simply creating the user page accesor interfaces. The next stage needs to be mucking with get_user_pages() so that we can control when the flush_dcache_page() occurs. Then we: 1) For every platform where flush_dcache_page() is a non-nop add a call to the beginning of copy_{from,to}_user_page(). 2) Make access_process_vm() set the "no dcache flush" bit in it's call to get_user_pages(). The idea also was that we'd consolidate the write etc. boolean args passed to get_user_pages() into flag bits too. But at least with the below, we can delete that reminder FIXME comment from kernel/ptrace.c, the platforms have the necessary tools and just need to make use of it :) As a bonus I noticed that VMALLOC_VMADDR() did absolutely nothing. After all of this I only have 1 real TODO left, and that's dealing with the SMP TLB/pte invalidation stuff, very low priority until someone starts doing more work with sparc32/SMP in 2.6.x :)

[PATCH] Remove flush_page_to_ram()

2003-04-12T19:55:02Z

From: Hugh Dickins This patch removes the long deprecated flush_page_to_ram. We have two different schemes for doing this cache flushing stuff, the old flush_page_to_ram way and the not so old flush_dcache_page etc. way: see DaveM's Documentation/cachetlb.txt. Keeping flush_page_to_ram around is confusing, and makes it harder to get this done right. All architectures are updated, but the only ones where it amounts to more than deleting a line or two are m68k, mips, mips64 and v850. I followed a prescription from DaveM (though not to the letter), that those arches with non-nop flush_page_to_ram need to do what it did in their clear_user_page and copy_user_page and flush_dcache_page. Dave is consterned that, in the v850 nb85e case, this patch leaves its flush_dcache_page as was, uses it in clear_user_page and copy_user_page, instead of making them all flush icache as well. That may be wrong: I'm just hesitant to add cruft blindly, changing a flush_dcache macro to flush icache too; and naively hope that the necessary flush_icache calls are already in place. Miles, please let us know which way is right for v850 nb85e - thanks.

[SPARC]: Move away from flush_page_to_ram.

2003-02-09T18:46:43Z

SPARC32: First pass at getting this platform functional under 2.5.x

2002-07-16T10:12:46Z