diff options
author | Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com> | 2015-07-22 09:26:02 -0300 |
---|---|---|
committer | Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com> | 2015-10-19 16:58:03 -0200 |
commit | 6ec52bf634b7650b57ff67b5f5053bce8992d549 (patch) | |
tree | e82562c4a74866a1b7cdabc79311d3a58a6e3729 /debug/fdelt_chk.c | |
parent | 44f826e317f28969ea6ca0e87aa4c6b69c819245 (diff) | |
download | glibc-6ec52bf634b7650b57ff67b5f5053bce8992d549.tar.gz glibc-6ec52bf634b7650b57ff67b5f5053bce8992d549.tar.xz glibc-6ec52bf634b7650b57ff67b5f5053bce8992d549.zip |
PowerPC: Fix a race condition when eliding a lock
The previous code used to evaluate the preprocessor token is_lock_free to a variable before starting a transaction. This behavior can cause an error if another thread got the lock (without using a transaction) between the evaluation of the token and the beginning of the transaction. This bug can be triggered with the following order of events: 1. The lock accessed by is_lock_free is free. 2. Thread T1 evaluates is_lock_free and stores into register R1 that the lock is free. 3. Thread T2 acquires the same lock used in is_lock_free. 4. T1 begins the transaction, creating a memory barrier where is_lock_free is false, but R1 is true. 5. T1 reads R1 and doesn't abort the transaction. 6. T1 calls ELIDE_UNLOCK, which reads false from is_lock_free and decides to unlock a lock acquired by T2, leading to undefined behavior. This patch delays the evaluation of is_lock_free to inside a transaction by moving this part of the code to the macro ELIDE_LOCK. [BZ #18743] * sysdeps/powerpc/nptl/elide.h (__elide_lock): Move most of this code to... (ELIDE_LOCK): ...here. (__get_new_count): New function with part of the code from __elide_lock that updates the value of adapt_count after a transaction abort. (__elided_trylock): Moved this code to... (ELIDE_TRYLOCK): ...here.
Diffstat (limited to 'debug/fdelt_chk.c')
0 files changed, 0 insertions, 0 deletions