On Tue, Nov 28, 2006 at 04:09:11PM -0500, Tom Lane wrote:
> The mmap man page is pretty vague on the subject, but I wonder whether
> the shlib isn't effectively treated as copy-on-write --- that is, any
> attempted overwrite of the file happens only after the mmap region has
> been fully copied. Without that, it'd be impossible to update core
> shared libraries like libc.so without a system reboot, but Linux doesn't
> seem to need that.
Hmm? To upgrade libc.so you merely need to delete the old one and
install the new one, there's no need to preserve the inode. The mmap()
is private, but no, Linux does not keep a backup copy of the shared
library if you overwrite it. The behaviour of overwriting the backing
store of a private mapping is explicitly undefined.
I did some digging. At one point there was protection for overwriting
shared libraries, you could pass MAP_DENYWRITE to mmap(), which would
cause any writes to the file to fail with ETXTBSY, just like it does
for normal executables. However:
MAP_DENYWRITE
This flag is ignored. (Long ago, it signalled that attempts to
write to the underlying file should fail with ETXTBUSY. But this
was a source of denial-of-service attacks.)
> I suspect that this issue is specific to dlsym() and has nothing to do
> with the safeness of ordinary usage of a shared library. The reason
> 8.2 is getting bit is that it tries to do a dlsym() lookup during shlib
> unload, which we never did before. (Merlin, I assume you have been
> doing the same things with 8.1 and before without a problem?)
I wouldn't be surprised if this were the problem. People testing shared
libraries would probably not be testing what happened between the time
the shared-library was overwritten and the LOAD command was reexecuted.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
