Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!agate!howland.reston.ans.net!news.sprintlink.net!news.bluesky.net!news.mathworks.com!news.kei.com!nntp.et.byu.edu!news.byu.edu!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@cs.weber.edu>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Static vs. Shared binaries in /
Date: 9 Jun 1995 01:55:58 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 76
Message-ID: <3r89ne$bbo@park.uvsc.edu>
References: <3qfn52$188j@troy.la.locus.com> <3qo3m8$aq7@park.uvsc.edu> <87zqjsxxxj.fsf@interbev.mindspring.com>
NNTP-Posting-Host: hecate.artisoft.com
rsanders@interbev.mindspring.com (Robert Sanders) wrote:
] On 8 Jun 1995 18:24:16 GMT, nate@trout.sri.MT.net (Nate Williams) said:
]
] > I ran with a shared / for awhile, and I hated it. Basicaly, my system
] > went completely belly-up when I replaced libc.so since all of the entry
] > points of running programs changed. This is *not* good with a system
] > that uses the FS binaries for backing store.
]
] Um, the new libc.so would have a different inode number, right? So
] already running programs wouldn't be using it. The old libc.so would
] be either renamed or unlinked; however, since the in-core vnode was
] still in use, it would also still be available for programs that were
] using it. This is the same thing that happens when you unlink() an
] open file.
]
] You may have had problems with a shared /, but that doesn't seem like
] a valid explanation.
I think Nate's problem is related to the fact that the shared
library is used as a swap backing store (something I don't like
anyway for reasons I won't get into here -- it'll start yet another
big discussion) *AND* the mmap() incorrectly does not us mprotect()
to set the VTEXT bit on the vnode so that attempts to write the
library itself will result in an "ETXTBUSY" error instead of
succeeding. The result is that the system is clobbered.
What Nate is neglecting is that the most-minor version number should
be incremented on a per build basis, since the ldconfig database is
(also incorrectly, IMO) consulted instead of traversing the dir
containing the libs to find libraries that are "missing".
The point here is version control between an active developement
system and an end user system, since any other approach will result
in the mv being successful at renaming the currently referenced
libc library, but then cp/install being unable to find a libc to
allow them to run to install the replacement (whereas a fallback
to a search would find the new library, no problem).
There are also basically two VM techniques that would allow the
executing image to be overwritten; the first is to fault the
existing refrence to backing store, since the write modification
time can be used as a key. That means that the pages go to real
swap in the event of an overwrite. This would get rid of user
ETXTBUSY errors, but leaves NFS problems.
The second technique is page-based pseudo-dirty marking and
reference predecrement. This would leave the pages in core (and
cause them to go to swap if the real memory needed to be recovered).
Effectively, an alias vnode for the dirty pages would be created,
and the fault would be on the per page overwrite as it occurred.
This second technique is useful for a linear copy, but prone to
causing processes to error if they are started *during* the copy
(tiny error window, but it exists). The other downside is that
the mmap() for cp would have to be forced to fail (easy: check
VTEXT), and it would leave the same NFS hole that currently exists
in the use of ETEXT.
Personally, I think the mprotect/ldconfig search path fallback
needs to be used, with the minor nit that a file open for write
not be allowed to be mapped as TEXT, and that a sequential retry
of older and older versions should take place rather than just
failing the cp/install libc open attempt on a partially copied
libc (the failure would occur on the mprotect() call, not the
mmap() call -- a reasonable failure mode in any case.
Either way, the argument is based on a two bug interaction that
should have been fixed long ago, and not doing something because
of bugs (that should be squashed instead) is bad policy.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.