I've had this discussion with Chuck Cranor a number of times,
and the conclusion we came to is that we don't need to track
the virtual addresses of k-mappings if we're careful about
when we use them.  the original purpose for k-mappings was
loaning, where all mappings of the page would be read-only
and so the usual VAC issues weren't relevant.  since then
I've also started work on using them in other places where
they are safe.  the other safe uses of k-mappings are

 (1) when it is known that there are no other mappings of the page,
     such as when we extending a file with write().  here the page
     is held busy from the time it's created until we're done with
     the k-mapping, so by the time there can be an alias the k-mapping
     is gone.

 (2) when we're reading the page from memory to write it to backing store.
     this use also involves careful ordering of operations in
     pmap_clear_modify(), so that any writes to the page via other
     mappings which could end up in different cache lines will also
     result in the page being marked modified again, so that we'll
     be forced to write the page to backing store again at some point
     in the future.


also, there can be multiple k-mappings at the same time as long as
they're only used for reading.

-Chuck



On Mon, Jul 09, 2001 at 11:23:48PM +0100, Chris Gilbert wrote:
> I'm wondering if there's now a need to indicate that a page has been 
> k-mapped?  As we can now have a page be k-mapped, and then also mapped into 
> the kernel pmap, which means that the page needs to be flagged as 
> non-cacheable/bufferable in both places, and potentially also store the place 
> the page was kmapped to.
> 
> Is this kind of check/protection needed?
> 
> Cheers,
> Chris