This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/18743] PowerPC: findutils testcase fails with --enable-lock-elision
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 19 Oct 2015 19:00:56 +0000
- Subject: [Bug nptl/18743] PowerPC: findutils testcase fails with --enable-lock-elision
- Auto-submitted: auto-generated
- References: <bug-18743-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18743
--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".
The branch, master has been updated
via 6ec52bf634b7650b57ff67b5f5053bce8992d549 (commit)
from 44f826e317f28969ea6ca0e87aa4c6b69c819245 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6ec52bf634b7650b57ff67b5f5053bce8992d549
commit 6ec52bf634b7650b57ff67b5f5053bce8992d549
Author: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Date: Wed Jul 22 09:26:02 2015 -0300
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.
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 12 ++++
NEWS | 14 +++---
sysdeps/powerpc/nptl/elide.h | 115 +++++++++++++++++++++++-------------------
3 files changed, 82 insertions(+), 59 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.