Date: Mon, 17 Jul 2000 10:18:14 -0700 (PDT) From: John Polstra <jdp@FreeBSD.org> To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/libexec/rtld-elf/alpha lockdflt.c src/libexec/rtld-elf/i386 lockdflt.c Message-ID: <200007171718.KAA25583@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
jdp 2000/07/17 10:18:14 PDT
Modified files:
libexec/rtld-elf/alpha lockdflt.c
libexec/rtld-elf/i386 lockdflt.c
Log:
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>
Revision Changes Path
1.6 +25 -2 src/libexec/rtld-elf/alpha/lockdflt.c
1.6 +33 -3 src/libexec/rtld-elf/i386/lockdflt.c
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007171718.KAA25583>