[krbdev.mit.edu #3293] use more caution in testing for pthread_mutex_lock

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[krbdev.mit.edu #3293] use more caution in testing for pthread_mutex_lock

Greg Hudson via RT
>From a recent bug report on kerberos@mit from Jon DeVree, with some help
in the analysis from Russ Allbery and Sam:

On Linux (GNU libc and friends), if nsswitch.conf enables ldap lookups
for "passwd", and if libnss_ldap pulls in the pthread library (as it
does in Debian "unstable" at the moment), kinit can hang trying to lock
a mutex after the password has been entered, in certain circumstances.

The problem:

Our current thread support tests to see if pthread_mutex_lock is defined
in the C library, and if it is, turns off the run-time weak-reference
test we used to do.  I think we used to test just the address of
pthread_mutex_lock, so turning off that test made sense; we do more
thorough tests now.

GNU libc has stub definitions for the pthread_mutex_* functions, so we
can call pthread_mutex_init in the C library.  Then when we look up the
name for the current uid via getpwuid (which uses nsswitch, which loads
libnss_ldap) the pthread library gets loaded.  Then we call
pthread_mutex_lock from libpthread, which doesn't seem to like the
initialization done by the C library stub.  While it can certainly be
argued that this combination of effects is a GNU libc (or ldap library)
bug, we should work around it.

Simple fix: Define USE_PTHREAD_LOCK_ONLY_IF_LOADED on all systems
supporting weak references, even if libc appears to have
pthread_mutex_lock (and even if it's the real thing, and compatible with
the thread library, unless we can identify either the working or failing
systems).

Slightly more complicated fix: USE_PTHREAD_LOCK_ONLY_IF_LOADED and
HAVE_PRAGMA_WEAK_REF are each used in different places to decide whether
to do the run-time test or the unconditional call.  We should have only
one macro for this, and probably not make it explicitly dependent on the
#pragma implementation.
_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs