Hi,
The race leads either to pthread_mutex_destroy returning EBUSY
or triggering an assertion (See description in bugzilla).
This patch is fixing the race by ensuring that the elision
path is used in all cases if elision is enabled by the
GLIBC_TUNABLES framework.
The __kind variable in struct __pthread_mutex_s is accessed
concurrently. Therefore we are now using the atomic macros.
The new testcase tst-mutex10 is triggering the race on s390x
and intel. Presumably also on power, but I don't have access
to a power machine with lock-elision. At least the code for
power is the same as on the other two architectures. Can
somebody test it on power?
Bye
Stefan
ChangeLog:
[BZ #23275]
* nptl/tst-mutex10.c: New File.
* nptl/Makefile (tests): Add tst-mutex10.
(tst-mutex-ENV): New variable.
* sysdeps/unix/sysv/linux/s390/force-elision.h:
(FORCE_ELISION):
Ensure that elision path is used if elision is available.
* sysdeps/unix/sysv/linux/powerpc/force-elision.h
(FORCE_ELISION): Likewise.
* sysdeps/unix/sysv/linux/x86/force-elision.h:
(FORCE_ELISION):
Likewise.
* nptl/pthreadP.h (PTHREAD_MUTEX_TYPE,
PTHREAD_MUTEX_TYPE_ELISION, PTHREAD_MUTEX_PSHARED):
Use atomic_load_relaxed.
* nptl/pthread_mutex_consistent.c
(pthread_mutex_consistent):
Likewise.
* nptl/pthread_mutex_getprioceiling.c
(pthread_mutex_getprioceiling): Likewise.
* nptl/pthread_mutex_lock.c (__pthread_mutex_lock_full,
__pthread_mutex_cond_lock_adjust): Likewise.
* nptl/pthread_mutex_setprioceiling.c
(pthread_mutex_setprioceiling): Likewise.
* nptl/pthread_mutex_timedlock.c
(__pthread_mutex_timedlock):
Likewise.
* nptl/pthread_mutex_trylock.c (__pthread_mutex_trylock):
Likewise.
* nptl/pthread_mutex_unlock.c (__pthread_mutex_unlock_full):
Likewise.
* sysdeps/nptl/bits/thread-shared-types.h
(struct __pthread_mutex_s): Add comments.
* nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy):
Use atomic_load_relaxed and atomic_store_relaxed.
* nptl/pthread_mutex_init.c (__pthread_mutex_init):
Use atomic_store_relaxed.