[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: iohelp handle_io_release_conch doesn't lock shared page

From: Roland McGrath
Subject: Re: iohelp handle_io_release_conch doesn't lock shared page
Date: Sat, 11 May 2002 16:59:36 -0400 (EDT)

> Linux doesn't allow any writes to shared libraries or executables that are
> currently running:

We know.  It sucks wet goat farts.

> For shared libraries, we use MAP_COPY.  Maybe we can use this for
> executables, too?

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).
The ideal would be if we had a new VM interface to make the virtual copy
and return a new memory object port referring to it.  Then we could do a
single io_map, vm_copy_object and make all mappings through the copy
object.  But in fact, it needs more than that since it needs to include its
stat for getting the file size as part of the atomic unit with the
mappings.  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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]