> It's a known problem - and a nasty one. Basically a good solution requires
> a way to map a page's physical address to virtual addresses. And Linux 2.2's
> mm will not provide this feature. Reverse mappings are under planning for
> 2.3 for other improvments. It was my plan to ignore this bug for now and
> deal with virtual coherency when reverse mappings are implemented in 2.3.
> Oh, I've already implemented the solution for the special case of ZERO_PAGE.
> On CPUs which know about the virtual coherency exception have eight colours
> for zero page. The change is basically to pass in the virtual address to
> ZERO_PAGE such that we always do ``colourly correct'' allocation. That was
> the simple case.
On the machines without VCE detection (R4000PC, R4600, R5000),
the zero page is safe, because it is read-only. Anonymous pages
are not an issue, since they are not double-mapped.
What is wrong with going from the mem_map_t.inode to the
inode.i_mmap list of mappings, and thence to the PTEs? IRIX, at least
before IRIX 6.5, does the equivalent to solve this problem.
> > How does IRIX solve this problem ? Does it disable caching for shared
> > writeable pages ?
> Mapping shared writeable pages uncached is not the solution. The virtual
> coherency problem in Linux/MIPS may happen between multiple userspace
> mappings or userspace and kernelspace, that is KSEG0, mappings. While
> we could disable caching for certain pages in the hope that we'll only
> end up with a few uncached pages making KSEG0 uncached is completly
> unacceptable performancewise. However, if we don't, then we might end up
> with aliases between userspace pages and KSEG0 pages.
You can use KSEG2 instead of KSEG0 for all pages which might be
mapped into user space. IRIX mostly does that, and keeps the KSEG2 mapping
around only as long as necessary, and then only with the current virtual
color (the color which currently has write ownership of the page) locked
(which means that references via other colors block until the kernel
gives up its mapping).