copy-on-write anonymous memory?

Mark Tinguely tinguely at casselton.net
Fri May 16 14:48:43 UTC 2008


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


More information about the freebsd-hackers mailing list