In other words, if the page is modified in user space, kernel needs
to call flush_dcache_page() in order to see the change properly.
Vice versa.
One immediate problem we have is that given the struct page
pointer argument to this function we have no way of knowing the user
space virture address of that page (without searching through the whole
page table). And worse, we might have multiple mappings of the same
page to different user processes at the different virtual addresses.
If a MIPS cpu has a virtually-indexed dcache and has cache aliasing
problem, we need to know those user space vritual addresses
to flush this page properly. I suspect some other CPU architectures
should have this problem too. True?
So my question is: how other CPU arches with the same problem
implement flush_dcache_page()? Flushing the whole cache? Or
have a broken implementation and pretend it is OK? :)
BTW, I assume this is not a big problem in 2.5 as we have reverse page
mapping.
Cheers.
Jun
-
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/