Messages in this thread | | | Date | Fri, 23 May 2003 03:45:51 -0700 | From | Andrew Morton <> | Subject | Re: [patch] cache flush bug in mm/filemap.c (all kernels >= 2.5.30(at least)) |
| |
"Lothar Wassmann" <LW@KARO-electronics.de> wrote: > > Andrew Morton writes: > > "Lothar Wassmann" <LW@KARO-electronics.de> wrote: > > > > > > And maybe because *every* other call to flush_page_to_ram() has been > > > replaced by one of the new interface macros except that one in > > > filemap_nopage() in 'mm/filemap.c'. > > > > > > > flush_page_to_ram() has been deleted from the kernel. > > > Yes, I know. But did you even read, what I have written?
Vaguely. It never hurts to repeat things ;)
> Is 2.5.68 current enough?
yes.
filemap_nopage isn't the right place to be doing these things though.
Given that there was no page at the virtual address before filemap_nopage was called I don't think any CPU cache writeback or invalidation need be performed. Perhaps a writeback or invalidate is missing somewhere in the unmap paths, or there is a problem in arch/arm somewhere.
We have a no-op flush_icache_page() in do_no_page(), but I don't know what that thing ever did, not what it's doing in there. (What happens if you replace it with a flush_cache_page(vma, address)?)
Someone who understands these things better than I is going to have to work out where the bug really is, I'm afraid.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |