Re: iohelp handle_io_release_conch doesn't lock shared page

[Niels Möller]

Roland McGrath <roland@frob.com> writes:

> We do.  The virtual copying behavior is enabled by a Boolean argument to
> vm_map.  The issue is having several mappings together as an atomic unit
> relative to intervening write calls (or modifications via shared
> mmap).

One could get the (suckish) linux behaviour by somehow locking the
file at the start of the exec processing, and releasing it at process
death or exec.

> One idea is a call like `io_snapshot' that creates a new port
> that gives read-only access to the state of the node as it was when
> snapshot'd.  It would be unduly hairy to implement the file-data part of
> that in the filesystem, except by using vm_copy_object (which doesn't exist).

That sounds quite similar to implementing versioning in the
filesystem. Something like setting a snapshot-flag on the inode, and
at the next write to the file, you create a new inode that's copy of
the snapshot (either a full copy or some copy-on-write thing).

As the common case should be that the file you have a snapshot of is
*not* written to, I think it would be acceptable to make a full copy
at the first write.

But one case that snapshotting does not solve, as far as I can tell,
is the following:

  fd = open ("/bin/bash", O_WRONLY | O_TRUNC | CREAT);
  write(fd, first half of the binary);

  exec("/bin/bash", ...); /* By some other process */

  write(fd, second half of the binary);
  
To me it seems, one must also make sure that the snapshot is made at a
moment when no process have the file open for writing (or more
prceisely: There's no process that has written data to the file, and
still has the file open for writing).

If some useful snapshoting is ever implemented, it would be nice to be
able to get a snapshot by just opening the file with O_RDONLY |
O_SNAPSHOT.

I agree it seems quite hairy to get it both robust and reliable.
/Niels