copy-on-write anonymous memory?

[Teemu Rinta-aho]

Mark Tinguely wrote:
> Teemu Rinta-aho wrote (some edits):
> 
>>  I have created a kernel module that stores references to memory objects.
>>  I.e. when a process makes a syscall to the module, it will create a
>>  snapshot of the memory area, and after that the writes from the process to
>>  that memory area should create a shadow object. The next syscall should
>>  again store a pointer to the current topmost shadow object and then the
>>  next write creates yet another shadow object. Etc... When the snapshots
>>  are removed, the shadow chains may collapse normally.
>>
>>  Here's an illustration of what I want (first syscall OK, second one not):
>>
>>       * Legend: U/u = userspace K/k = kernel
>>       *
>>       * U:vm_map_entry_u -> object
>>       *             ||
>>       *           SYSCALL
>>       *             ||
>>       *             \/
>>       * U:vm_map_entry_u -> object_shadow -> object
>>       *                                  /
>>       * K:vm_map_entry_k ----------------
>>       *             ||
>>       *           SYSCALL
>>       *             ||
>>       *             \/
>>       * U:vm_map_entry_u -> object_shadow -> object_shadow -> object
>>       *                                  /                /
>>       * K:vm_map_entry_k ----------------                /
>>       * K:vm_map_entry_k --------------------------------
>>
>>  Now, the problem is that the first snapshot works as it should. However,
>>  the second one doesn't, and  the write goes to the one and same shadow
>>  object, even if I restore MAP_ENTRY_COW and MAP_ENTRY_NEEDS_COPY manually
>>  in my handler function which is storing the snapshot.
>>
>>  Any ideas?
> 
> Usually, a fork() creates the inheritance between parent and child COW memory
> space. Start:
>    vm_map_entry -> object_shadow -> object
> 
> fork():
>    vm_map_entry -> object_shadow -\
>                                    |-> (object_shadow*) -> object
>    vm_map_entry -> object_shadow -/
> 
> This is slightly different from your description/drawing, in the way changes
> are inherited; for example: process 1 is created, process 1 writes page 0.
> process 2 is created. process 1 writes p1 (or p0 again). Your
> description/drawing implies that process 2 see this change from process 1.
> 
> You are not forking over a COW memory area. Sounds like the syscall will have
> manually create the inheritance. You can manually link the object_shadows
> the way you want to get the desired inheritance. Process removals should
> collapse the shadows automatically.
> 
> Matt Dillion wrote a brief VM description
> (http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/).
> The book, "The Design and Implementation of the 4.4BSD Operating System"
> is another great reference.
> 
> Mark Tinguely

Hi Mark,

thanks a lot. I was just about to write to the list that I found the
solution, to give future Googler's some help :-)

The problem was that of course there is no page fault for every
write to the same page. However, I can manually set the COW flag in the map
entry, and then call pmap_protect() to set the physical page read only.
Then the next write after the syscall will trigger the vm_map_lookup()
and the creation of a shadow object.

So, for now, this problem is solved. I'm about to head towards
new problems now :-)

Best regards,
Teemu Rinta-aho

P.S. Yes I have both the D&I of 4.4BSD and D&I of FreeBSD books,
they're quite good and become understandable after browsing the
code for a while :-)