Questions about copy-on-write

[Sam Mason]

Marcus Brinkmann wrote:
>The filesystem makes a logical copy of the page from its cache into
>the container provided by the client, marked copy-on-write.

I'm fine with everything up to here. . .

>Then the
>page can be mapped into the client (read-only).

Physmem will change the mappings in both tasks so they're read-only
wont it?

>When a write page
>fault arises, and the client forces a writable mapping, physmem will
>make the physical copy.  

Again, the original distinction between the original sharer and
receiver would have already been lost and the final task still having
a mapping of the page could be given full read-write permissions
to the original page.

>So, COW is implemented lazily.

In other news: Performance increases have been attributed to the
recent introduction of lazy COWs to the Hurd . .

>Note that copying from container to container is usually not a memcpy,
>but a logical copy of frame references.

That bit makes sense as well.

One thing I'm still uncertain about is if a task can (in general)
modify another tasks mappings.  I would've thought that would be
a capability limited to only trusted tasks - like physmem, or a
thread's pager.

Assuming that is the case, the involvement of physmem in this
procedure is only to ensure that neither task accidentally leaves
a page mapped as read-write.

  Sam