From e803829e6b087c0ed91adc11f87185109bc59b31 Mon Sep 17 00:00:00 2001 From: Rich Felker Date: Fri, 20 Sep 2013 02:00:27 -0400 Subject: fix potential deadlock bug in libc-internal locking logic if a multithreaded program became non-multithreaded (i.e. all other threads exited) while one thread held an internal lock, the remaining thread would fail to release the lock. the the program then became multithreaded again at a later time, any further attempts to obtain the lock would deadlock permanently. the underlying cause is that the value of libc.threads_minus_1 at unlock time might not match the value at lock time. one solution would be returning a flag to the caller indicating whether the lock was taken and needs to be unlocked, but there is a simpler solution: using the lock itself as such a flag. note that this flag is not needed anyway for correctness; if the lock is not held, the unlock code is harmless. however, the memory synchronization properties associated with a_store are costly on some archs, so it's best to avoid executing the unlock code when it is unnecessary. --- src/internal/libc.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src/internal') diff --git a/src/internal/libc.h b/src/internal/libc.h index 3350b3d1..d625b56a 100644 --- a/src/internal/libc.h +++ b/src/internal/libc.h @@ -53,8 +53,8 @@ void __lock(volatile int *) ATTR_LIBC_VISIBILITY; void __unlock(volatile int *) ATTR_LIBC_VISIBILITY; int __lockfile(FILE *) ATTR_LIBC_VISIBILITY; void __unlockfile(FILE *) ATTR_LIBC_VISIBILITY; -#define LOCK(x) (libc.threads_minus_1 ? (__lock(x),1) : ((void)(x),1)) -#define UNLOCK(x) (libc.threads_minus_1 ? (__unlock(x),1) : ((void)(x),1)) +#define LOCK(x) __lock(x) +#define UNLOCK(x) __unlock(x) void __synccall(void (*)(void *), void *); int __setxid(int, int, int, int); -- cgit 1.4.1