1
0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-17 10:26:15 +00:00
freebsd/libexec/rtld-elf/i386
John Polstra cf98e66403 Fix a bug which could cause programs with user threads packages to
lock against themselves, causing infinite spinning.  Brian Feldman
found this problem when testing with Mozilla and supplied the fix,
which I have revised slightly.

Here is the failure scenario.  A thread calls dlopen() and acquires
the writer lock.  While the thread still holds the lock, a signal
is delivered and caught.  The signal handler tries to call a function
which hasn't been bound yet.  It thus enters the dynamic linker
and tries to acquire the reader lock.  Since the writer lock is
already held, it will spin forever in the signal handler.  The
thread holding the lock won't be able to progress and release the
lock.

The solution is to block almost all signals while holding the
exclusive lock.

A similar problem could conceivably occur in the opposite order.
Namely, a thread is holding the reader lock and then a signal
handler calls dlopen() or dlclose() and spins waiting for the writer
lock.  We deal with this administratively by proclaiming that signal
handlers aren't allowed to call dlopen() or dlclose().  Actually
we don't have to proclaim a thing, since signal handlers aren't
allowed to call any system functions except those which are explicitly
permitted.

Submitted by:	Brian Fundakowski Feldman <green>
2000-07-17 17:18:13 +00:00
..
elf_rtld.x Eliminate all machine-dependent code from the main source body and 1999-04-09 00:28:43 +00:00
lockdflt.c Fix a bug which could cause programs with user threads packages to 2000-07-17 17:18:13 +00:00
Makefile.inc Eliminate all machine-dependent code from the main source body and 1999-04-09 00:28:43 +00:00
reloc.c When a threads package registers locking methods with dllockinit(), 2000-01-29 01:27:04 +00:00
rtld_machdep.h Solve the dynamic linker's problems with multithreaded programs once 2000-07-08 04:10:38 +00:00
rtld_start.S $Id$ -> $FreeBSD$ 1999-08-28 00:22:10 +00:00