bugs@shire.cs.psu.edu (08/20/89)
Serial Number: 922E0914
Machine Type: Sun 4/280
O/S Version: SunOS 4.0.3
Organization: Computer Science Department, The Pennsylvania State University
333 Whitmore Laboratory, University Park, PA 16802
Phone Number: +1 814 865 9723
Description:
In pure 4.3BSD when an executable is being executed (and paged
out of) the kernel refuses to allow it to be overwritten,
returning instead the error ETXTBSY ("text file busy"). In SunOS,
programs like "cp" use mmap, which succedes in overwriting the
busy text file, usually aborting the executing instance of the
first program. My intuition is that mmap should return ETXTBSY
in this case instead.
Repeat-By:
Run a program in the background, and then copy something else
on top of it with "cp".
I only tried this with local disks. Who knows what NFS will do?
-- Scott Schwartz <schwartz@shire.cs.psu.edu>guy@uunet.uu.net (Guy Harris) (09/02/89)
> In SunOS, programs like "cp" use mmap, which succedes in > overwriting the busy text file, usually aborting the executing > instance of the first program. This has nothing to do with "mmap"; try it with "dd", which doesn't use "mmap". (In fact, "cp" uses "mmap" only on the *input* files; it does a "write" to the output file, writing from the mapped-in area.) > My intuition is that mmap should return ETXTBSY in this case > instead. In what case? Trying to map a shared-text file read-write? The "right" place to to catch that might be "open"; however, SunOS 4.0 doesn't have "shared texts", so that's a little hard. What are, in other flavors of UNIX, "shared texts" are in 4.0 just copy-on-write mappings to a file - the copy-on-write part allows you, for example, to run a debugger on a program that's being run by others, since the breakpoints get set in private copies of the pages on which they're being set. Other extremely similar copy-on-write mappings include mappings to shared libraries, and you *have* to be able to map them read-write, since PIC isn't 100% PI and some relocation has to be done. The only real fix to this would be to arrange that modifying a page that has a shared writable mapping to a file causes the copy-on-write feature to be triggered on all copy-on-write mappings to that page; I don't know whether this change to the semantics of "mmap" would break anything else, or be a "surprising" change, and I don't know how difficult it would be. > I only tried this with local disks. Who knows what NFS will do? It'll do the same thing. In fact, even prior to 4.0 you could modify a file that machine A had mapped in as a shared-text segment, as long as you did it on a machine other than machine A, i.e., either the server or another of its clients.