Russell King wrote:
> Also, I believe that the use of flush_page_to_ram() is wrong here, since
> this seems to be intended to be used when the kernel has been writing to
> its direct mapped version of the page, which is should not have been (if
> it has, then the act of writing is a bug, not the apparantly missing call).
Thanks for the clarification. I see. OK. I withdraw the patch (of
vmsacan.c). It's wrong then.
I was confused and was not sure that flash_page_to_ram is only
flushing its direct mapped version of the kernel page or not. (SH4
version of flash_page_to_ram flushes the user space too (at this
time). If it doesn't flush user space, it fails.)
It's kernel page flush only. OK.
Then, there is another issue for physically tagged cache system in the
function memory.c:break_cow. It calles flush_cache_page(vma,
address). For physically tagged cache system, we need __physical
address__ here. Currently, the implementation of SH-4 version of
flush_cache_page(vma, address) takes the physicall address from PTE.
However, at this point, PTE is not set for new_page, so, it doesn't
flush the cache for new_page, but the one for old_page.
The interface flush_cache_page(vma, address) is perfect for virtually
tagged cache system. I think that it need another argument PAGE
for physically tagged cache system. Say:
flush_cache_page(vma, address, page)
Any comments are appreciated.
Thanks,
-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:14 EST