* [Bug nptl/16657] Lock elision breaks pthread_mutex_trylock
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
@ 2014-03-04 12:03 ` schwab@linux-m68k.org
2014-03-04 17:51 ` bugdal at aerifal dot cx
` (44 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: schwab@linux-m68k.org @ 2014-03-04 12:03 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
Created attachment 7450
--> https://sourceware.org/bugzilla/attachment.cgi?id=7450&action=edit
Properly handle forced elision in pthread_mutex_trylock
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_trylock
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
2014-03-04 12:03 ` [Bug nptl/16657] " schwab@linux-m68k.org
@ 2014-03-04 17:51 ` bugdal at aerifal dot cx
2014-03-05 0:32 ` andi-bz at firstfloor dot org
` (43 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: bugdal at aerifal dot cx @ 2014-03-04 17:51 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
This patch looks inconsistent with the comment that happened to get quoted in
it from line 33:
/* We don't force elision in trylock, because this can lead to inconsistent
lock state if the lock was actually busy. */
There was a huge thread on the mailing list about elision and trylock with
normal-type mutexes at the time elision was added, and I'm highly skeptical of
such a trivial-looking fix; it seems to break trylock semantics.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_trylock
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
2014-03-04 12:03 ` [Bug nptl/16657] " schwab@linux-m68k.org
2014-03-04 17:51 ` bugdal at aerifal dot cx
@ 2014-03-05 0:32 ` andi-bz at firstfloor dot org
2014-03-05 1:12 ` bugdal at aerifal dot cx
` (42 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: andi-bz at firstfloor dot org @ 2014-03-05 0:32 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #3 from Andi Kleen <andi-bz at firstfloor dot org> ---
The patch is wrong. Adds a race.
The return value of pthread_mutex_destroy is undefined. I originally couldn't
find any software that cares about this, so it was changed. If someone really
cares about the return value the "right" change would be to add an abort to
destroy.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_trylock
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (2 preceding siblings ...)
2014-03-05 0:32 ` andi-bz at firstfloor dot org
@ 2014-03-05 1:12 ` bugdal at aerifal dot cx
2014-03-05 8:51 ` schwab@linux-m68k.org
` (41 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: bugdal at aerifal dot cx @ 2014-03-05 1:12 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> ---
pthread_mutex_destroy has no mandatory errors and has no way it can fail except
when undefined behavior has been invoked, so the cheapest solution would be
making it always return 0 if elision is in use.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_trylock
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (3 preceding siblings ...)
2014-03-05 1:12 ` bugdal at aerifal dot cx
@ 2014-03-05 8:51 ` schwab@linux-m68k.org
2014-03-05 14:14 ` matz at suse dot de
` (40 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: schwab@linux-m68k.org @ 2014-03-05 8:51 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #7450|0 |1
is obsolete| |
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_trylock
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (4 preceding siblings ...)
2014-03-05 8:51 ` schwab@linux-m68k.org
@ 2014-03-05 14:14 ` matz at suse dot de
2014-03-05 14:18 ` [Bug nptl/16657] Lock elision breaks pthread_mutex_detroy schwab@linux-m68k.org
` (39 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: matz at suse dot de @ 2014-03-05 14:14 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Michael Matz <matz at suse dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |matz at suse dot de
--- Comment #5 from Michael Matz <matz at suse dot de> ---
See e.g. https://bugzilla.novell.com/show_bug.cgi?id=865968 for software
that does check the return code of pthread_mutex_destroy. Andi: the return
value of _destroy is not undefined, it may fail with EBUSY or EINVAL under
very specific circumstances. In the case given it must not fail.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_detroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (5 preceding siblings ...)
2014-03-05 14:14 ` matz at suse dot de
@ 2014-03-05 14:18 ` schwab@linux-m68k.org
2014-03-05 17:57 ` bugdal at aerifal dot cx
` (38 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: schwab@linux-m68k.org @ 2014-03-05 14:18 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Lock elision breaks |Lock elision breaks
|pthread_mutex_trylock |pthread_mutex_detroy
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_detroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (6 preceding siblings ...)
2014-03-05 14:18 ` [Bug nptl/16657] Lock elision breaks pthread_mutex_detroy schwab@linux-m68k.org
@ 2014-03-05 17:57 ` bugdal at aerifal dot cx
2014-03-06 16:03 ` carlos at redhat dot com
` (37 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: bugdal at aerifal dot cx @ 2014-03-05 17:57 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> ---
It's certainly not "undefined", It's required to return 0 on success, and there
are no defined errors for destroy in POSIX, so any error returned would need to
be implementation-defined or occur only in the case of undefined behavior.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_detroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (7 preceding siblings ...)
2014-03-05 17:57 ` bugdal at aerifal dot cx
@ 2014-03-06 16:03 ` carlos at redhat dot com
2014-03-10 14:14 ` triegel at redhat dot com
` (36 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: carlos at redhat dot com @ 2014-03-06 16:03 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carlos at redhat dot com
--- Comment #7 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #6)
> It's certainly not "undefined", It's required to return 0 on success, and
> there are no defined errors for destroy in POSIX, so any error returned
> would need to be implementation-defined or occur only in the case of
> undefined behavior.
I agree. With elision you can't detect the EINVAL or EBUSY cases, therefore
returning 0 when elision is enabled is the best solution.
What do you think Andi?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_detroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (8 preceding siblings ...)
2014-03-06 16:03 ` carlos at redhat dot com
@ 2014-03-10 14:14 ` triegel at redhat dot com
2014-03-18 15:31 ` snyder at bnl dot gov
` (35 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: triegel at redhat dot com @ 2014-03-10 14:14 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Torvald Riegel <triegel at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |triegel at redhat dot com
--- Comment #8 from Torvald Riegel <triegel at redhat dot com> ---
I agree that we should return 0 -- but why do we see this in
pthread_mutex_destroy at all?
https://bugzilla.novell.com/show_bug.cgi?id=865968 states that nusers isn't
correct on destruction. If that's the case, ISTM that this should be fixed,
not anything in pthread_mutex_destroy.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_detroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (9 preceding siblings ...)
2014-03-10 14:14 ` triegel at redhat dot com
@ 2014-03-18 15:31 ` snyder at bnl dot gov
2014-04-04 22:31 ` andi-bz at firstfloor dot org
` (34 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: snyder at bnl dot gov @ 2014-03-18 15:31 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
scott snyder <snyder at bnl dot gov> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |snyder at bnl dot gov
--- Comment #9 from scott snyder <snyder at bnl dot gov> ---
Just switched to a new machine and promptly ran into this problem...
The boost thread wrappers check the abort on a failing return
from pthread_mutex_destroy:
~mutex()
{
BOOST_VERIFY(!posix::pthread_mutex_destroy(&m));
}
Locking multiple times, as in the attached test case, is not necessary;
i can reproduce the problem with sequence like this:
pthread_mutex_t m;
if (pthread_mutex_init(&m, NULL) != 0) abort();
pthread_mutex_trylock(&m);
pthread_mutex_unlock (&m);
if (pthread_mutex_destroy (&m) != 0) abort();
I think i see what the problem is.
In pthread_mutex_lock, we have this sequence:
if (__builtin_expect (type == PTHREAD_MUTEX_TIMED_NP, 1))
{
FORCE_ELISION (mutex, goto elision);
FORCE_ELISION sets the PTHREAD_MUTEX_ELISION_NP flag in the lock's
type field, and then proceeds to do the elided lock. The owner/users
fields are not updated in this case.
In pthread_mutex_unlock the first test fails because elision bit is set;
the second succeeds, and we do the elided unlock which again does not
change the owner/users flags:
if (__builtin_expect (type, PTHREAD_MUTEX_TIMED_NP)
== PTHREAD_MUTEX_TIMED_NP)
{
/* Always reset the owner field. */
...
}
else if (__builtin_expect (type == PTHREAD_MUTEX_TIMED_ELISION_NP, 1))
{
/* Don't reset the owner/users fields for elision. */
return lll_unlock_elision (mutex->__data.__lock,
PTHREAD_MUTEX_PSHARED (mutex));
In trylock, however, we use DO_ELISION rather than FORCE_ELISION:
case PTHREAD_MUTEX_TIMED_ELISION_NP:
elision:
if (lll_trylock_elision (mutex->__data.__lock,
mutex->__data.__elision) != 0)
break;
/* Don't record the ownership. */
return 0;
case PTHREAD_MUTEX_TIMED_NP:
if (DO_ELISION (mutex))
goto elision;
/*FALL THROUGH*/
DO_ELISION does _not_ set the elision bit in the type field.
If the lock was orginally free, the trylock succeeds, and does not
adjust the owner/user fields.
But then when we try to unlock after a trylock, the elision bit is still
clear. So we take the code path starting at the comment
/* Always reset the owner field. */
which proceeds to decrement the user field, corrupting the lock.
This problem might be fixable by changing the DO_ELISION in
pthread_mutex_trylock to FORCE_ELISION (though i haven't yet tried that).
I have checked that if i do a pthread_mutex_lock/pthread_mutex_unlock
on the lock before the first trylock, then the problem goes away,
as expected from the above analysis (since the lock will set the
elision flag).
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_detroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (10 preceding siblings ...)
2014-03-18 15:31 ` snyder at bnl dot gov
@ 2014-04-04 22:31 ` andi-bz at firstfloor dot org
2014-04-07 9:28 ` schwab@linux-m68k.org
` (33 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: andi-bz at firstfloor dot org @ 2014-04-04 22:31 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #10 from Andi Kleen <andi-bz at firstfloor dot org> ---
The reason I originally used DO_ELISION was that I was worried about two
parallel trylocks coming in here, and also corrupting the lock state.
But yes that fix may have been worse than the original problem, especially
since once the elision flag is set we don't care anymore.
So likely Andreas' original fix is the right one. Use FORCE_ELISION always.
Returning 0 in mutex_destroy would also work, but it could leave the mutex in
some awkward immediate state.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_detroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (11 preceding siblings ...)
2014-04-04 22:31 ` andi-bz at firstfloor dot org
@ 2014-04-07 9:28 ` schwab@linux-m68k.org
2014-05-28 12:09 ` cvs-commit at gcc dot gnu.org
` (32 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: schwab@linux-m68k.org @ 2014-04-07 9:28 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #7450|1 |0
is obsolete| |
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_detroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (12 preceding siblings ...)
2014-04-07 9:28 ` schwab@linux-m68k.org
@ 2014-05-28 12:09 ` cvs-commit at gcc dot gnu.org
2014-06-02 14:25 ` pspacek at redhat dot com
` (31 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-05-28 12:09 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #11 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, azanella/lockelision-ppc has been created
at 9e49e8d39848648aa8805fcaa0dacddbfc23cb2f (commit)
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9e49e8d39848648aa8805fcaa0dacddbfc23cb2f
commit 9e49e8d39848648aa8805fcaa0dacddbfc23cb2f
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Mar 21 08:26:59 2014 -0400
PowerPC: Adjusting LE mutex destroy
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2eb8801af5c5437a2fc611b37ef88be190b40d54
commit 2eb8801af5c5437a2fc611b37ef88be190b40d54
Author: Andreas Schwab <schwab@suse.de>
Date: Thu Mar 27 16:50:04 2014 -0400
Skip checks in pthread_mutex_destroy when doing elision
When doing elisison the __nusers field is not updated, thus can have an
arbitrary value.
[BZ #16657]
* nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy): Skip
checks when doing elision.
* nptl/sysdeps/unix/sysv/linux/x86/pthread_mutex_destroy.c: New
* file.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=81fae2105ca9a8384ccdf9ecc9a224c47fbce0a4
commit 81fae2105ca9a8384ccdf9ecc9a224c47fbce0a4
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Dec 13 15:59:35 2013 -0500
PowerPC: Add the low level infrastructure for pthreads lock elision
-----------------------------------------------------------------------
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_detroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (13 preceding siblings ...)
2014-05-28 12:09 ` cvs-commit at gcc dot gnu.org
@ 2014-06-02 14:25 ` pspacek at redhat dot com
2014-06-13 6:39 ` [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy fweimer at redhat dot com
` (30 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: pspacek at redhat dot com @ 2014-06-02 14:25 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Petr Špaček <pspacek at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pspacek at redhat dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-22642-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jun 02 18:18:52 2014
Return-Path: <glibc-bugs-return-22642-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 17296 invoked by alias); 2 Jun 2014 18:18:52 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 17257 invoked by uid 55); 2 Jun 2014 18:18:47 -0000
From: "GavinSmith0123 at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug manual/17011] Example in "Allocating Pseudo-Terminals" section uses isastream
Date: Mon, 02 Jun 2014 18:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: manual
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: GavinSmith0123 at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-17011-131-YHc1cfkFdU@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-17011-131@http.sourceware.org/bugzilla/>
References: <bug-17011-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00018.txt.bz2
Content-length: 804
https://sourceware.org/bugzilla/show_bug.cgi?id\x17011
--- Comment #5 from Gavin Smith <GavinSmith0123 at gmail dot com> ---
On Mon, Jun 2, 2014 at 2:15 PM, schwab@linux-m68k.org
<sourceware-bugzilla@sourceware.org> wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id\x17011
>
> --- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
> isastream is declared in <stropts.h>.
>
Including this file brought in the declaration and the I_PUSH
definition and the example code compiles fine with it. So the bug is
that it's not documented that you should include this file. If there
are any other situations where you should be calling isastream for
compatibility reasons, there should be documentation of this as well.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (14 preceding siblings ...)
2014-06-02 14:25 ` pspacek at redhat dot com
@ 2014-06-13 6:39 ` fweimer at redhat dot com
2014-06-16 16:41 ` fweimer at redhat dot com
` (29 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: fweimer at redhat dot com @ 2014-06-13 6:39 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Lock elision breaks |Lock elision breaks
|pthread_mutex_detroy |pthread_mutex_destroy
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (15 preceding siblings ...)
2014-06-13 6:39 ` [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy fweimer at redhat dot com
@ 2014-06-16 16:41 ` fweimer at redhat dot com
2014-06-16 16:49 ` bugdal at aerifal dot cx
` (28 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: fweimer at redhat dot com @ 2014-06-16 16:41 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |fweimer at redhat dot com
Resolution|--- |FIXED
--- Comment #12 from Florian Weimer <fweimer at redhat dot com> ---
Is it conceivable that this might trigger application aborts, resulting in
denial-service issues?
It appears that this was introduced with elision support in glibc 2.18, and
fixed in commit 2eb8801af5c5437a2fc611b37ef88be190b40d54/
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (16 preceding siblings ...)
2014-06-16 16:41 ` fweimer at redhat dot com
@ 2014-06-16 16:49 ` bugdal at aerifal dot cx
2014-06-16 16:55 ` fweimer at redhat dot com
` (27 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: bugdal at aerifal dot cx @ 2014-06-16 16:49 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #13 from Rich Felker <bugdal at aerifal dot cx> ---
Yes, see comment #5. But if you're asking about security flag, my impression
was that so far the security flag is only being used where the bug leads
directly to a security problem more serious than plain DoS.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (17 preceding siblings ...)
2014-06-16 16:49 ` bugdal at aerifal dot cx
@ 2014-06-16 16:55 ` fweimer at redhat dot com
2014-06-16 17:10 ` schwab@linux-m68k.org
` (26 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: fweimer at redhat dot com @ 2014-06-16 16:55 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #14 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Rich Felker from comment #13)
> Yes, see comment #5. But if you're asking about security flag, my impression
> was that so far the security flag is only being used where the bug leads
> directly to a security problem more serious than plain DoS.
I was asking about real-world application impact, e.g. "we discovered this bug
because Apache httpd was crashing after processing a certain sequence of
requests" (purely hypothetically speaking). It's not always easy to draw the
line between a reliability bug which manifests somewhat randomly, and a
denial-of-service vulnerability which can be triggered with some non-negligible
probability (which will approach 1 after a sufficient number of attempts).
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (18 preceding siblings ...)
2014-06-16 16:55 ` fweimer at redhat dot com
@ 2014-06-16 17:10 ` schwab@linux-m68k.org
2014-06-17 17:39 ` cvs-commit at gcc dot gnu.org
` (25 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: schwab@linux-m68k.org @ 2014-06-16 17:10 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #15 from Andreas Schwab <schwab@linux-m68k.org> ---
This hasn't been fixed yet.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (19 preceding siblings ...)
2014-06-16 17:10 ` schwab@linux-m68k.org
@ 2014-06-17 17:39 ` cvs-commit at gcc dot gnu.org
2014-06-25 19:23 ` cvs-commit at gcc dot gnu.org
` (24 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-06-17 17:39 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #16 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, azanella/lockelision-ppc has been created
at 1496dfe9b65f53746c749e25b3c09073afa8cb7a (commit)
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=1496dfe9b65f53746c749e25b3c09073afa8cb7a
commit 1496dfe9b65f53746c749e25b3c09073afa8cb7a
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Mar 21 08:26:59 2014 -0400
PowerPC: Adjusting LE mutex destroy
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=50ffc83fb6511eb63df4a8f4c03ab998da06488a
commit 50ffc83fb6511eb63df4a8f4c03ab998da06488a
Author: Andreas Schwab <schwab@suse.de>
Date: Thu Mar 27 16:50:04 2014 -0400
Skip checks in pthread_mutex_destroy when doing elision
When doing elisison the __nusers field is not updated, thus can have an
arbitrary value.
[BZ #16657]
* nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy): Skip
checks when doing elision.
* nptl/sysdeps/unix/sysv/linux/x86/pthread_mutex_destroy.c: New
* file.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=cb59eaef602f7980987ade60e4ad87315bcf49c3
commit cb59eaef602f7980987ade60e4ad87315bcf49c3
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Dec 13 15:59:35 2013 -0500
PowerPC: Add the low level infrastructure for pthreads lock elision
-----------------------------------------------------------------------
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (20 preceding siblings ...)
2014-06-17 17:39 ` cvs-commit at gcc dot gnu.org
@ 2014-06-25 19:23 ` cvs-commit at gcc dot gnu.org
2014-07-02 15:48 ` jmbnyc at gmail dot com
` (23 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-06-25 19:23 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #17 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, azanella/lockelision-ppc has been created
at 52b090ceaa0a26109bed23dbef41bd2c9c349fb6 (commit)
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=52b090ceaa0a26109bed23dbef41bd2c9c349fb6
commit 52b090ceaa0a26109bed23dbef41bd2c9c349fb6
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Jun 25 15:14:27 2014 -0400
PowerPC: Fix TLE for rwlock and cond vars
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=872a452a3cfb4e4998749a71070c361f4cc3687f
commit 872a452a3cfb4e4998749a71070c361f4cc3687f
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Jun 25 15:13:46 2014 -0400
PowerPC: Add adaptive elision to rwlocks
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8371e721e0420f41713386d105fa1089241b249c
commit 8371e721e0420f41713386d105fa1089241b249c
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Mar 21 08:26:59 2014 -0400
PowerPC: Adjusting LE mutex destroy
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=831e93ca666fd7423ef79cd54a3cc53047f37e62
commit 831e93ca666fd7423ef79cd54a3cc53047f37e62
Author: Andreas Schwab <schwab@suse.de>
Date: Thu Mar 27 16:50:04 2014 -0400
Skip checks in pthread_mutex_destroy when doing elision
When doing elisison the __nusers field is not updated, thus can have an
arbitrary value.
[BZ #16657]
* nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy): Skip
checks when doing elision.
* nptl/sysdeps/unix/sysv/linux/x86/pthread_mutex_destroy.c: New
* file.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ac7744c948ac85edd955cfaf4c3c96170e1fefee
commit ac7744c948ac85edd955cfaf4c3c96170e1fefee
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Dec 13 15:59:35 2013 -0500
PowerPC: Add the low level infrastructure for pthreads lock elision
-----------------------------------------------------------------------
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (21 preceding siblings ...)
2014-06-25 19:23 ` cvs-commit at gcc dot gnu.org
@ 2014-07-02 15:48 ` jmbnyc at gmail dot com
2014-07-02 16:19 ` bugdal at aerifal dot cx
` (22 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: jmbnyc at gmail dot com @ 2014-07-02 15:48 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Jeffrey M. Birnbaum <jmbnyc at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jmbnyc at gmail dot com
--- Comment #18 from Jeffrey M. Birnbaum <jmbnyc at gmail dot com> ---
I'm consistently seeing this issue when using pthread_mutex_trylock, i.e.
trylock does not work properly, it does not get the lock when I know that the
lock is not being held. Is there an ETA when it might be fixed.
I am using Fedora 19:
Linux ivybridge 3.13.10-200.fc20.x86_64 #1 SMP Mon Apr 14 20:34:16 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
and
GNU C Library (GNU libc) stable release version 2.18, by Roland McGrath et al.
Compiled by GNU CC version 4.8.2 20131212 (Red Hat 4.8.2-7).
Compiled on a Linux 3.12.8 system on 2014-01-23.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (22 preceding siblings ...)
2014-07-02 15:48 ` jmbnyc at gmail dot com
@ 2014-07-02 16:19 ` bugdal at aerifal dot cx
2014-07-02 17:19 ` jmbnyc at gmail dot com
` (21 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: bugdal at aerifal dot cx @ 2014-07-02 16:19 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #19 from Rich Felker <bugdal at aerifal dot cx> ---
Jeffrey, I don't see any indication that the issue you're experiencing is the
same as this one. If you have information that suggests it is, please share.
You might also check whether the fix for this bug fixed your issue. If you
don't have reason to believe it's the same bug, please file a new bug report
with details on your issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (23 preceding siblings ...)
2014-07-02 16:19 ` bugdal at aerifal dot cx
@ 2014-07-02 17:19 ` jmbnyc at gmail dot com
2014-07-02 18:07 ` bugdal at aerifal dot cx
` (20 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: jmbnyc at gmail dot com @ 2014-07-02 17:19 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #20 from Jeffrey M. Birnbaum <jmbnyc at gmail dot com> ---
Let me elaborate as to what I see and you can perhaps help me determine if it
is the same (or similar) issue reported here. If not, then I will submit a
separate bug report (TIA).
here is the an outline of the code being used:
// assume that construction result in pthread_mutex_trylock where an
// internal isLocked variable is set to true if the the call returns 0.
mutex_lock::try_lock_guard guard(_db_lock);
if (!guard.isLocked())
{
// assume timer is returning elapsed time in seconds
while(!guard.isLocked() && timer.elapsedTime() < 1.0)
{
millisleep(1);
guard.lock(); // will call try_lock and set locked flag inside guard
}
}
When I run this code compiled with gcc 4.8.2 on my Linux 3.12.8 system (with
Haswell processor) I observe that if try_lock fails to get the lock then it
never succeeds to to get the lock. And I know (from tracing) that the lock has
been released during the time that this code is executing (and that other
thread that does release does not attempt to get the lock more than once a
second).
At first I thought this might be a compiler bug where isLocked() is not being
reevaluated each time in the loop but then I came across this report which
makes me suspect it is an elision bug not a compiler bug. If it were a compiler
bug then I would be quite unnerved and would stop using gcc 4.8.2.
Does this help?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (24 preceding siblings ...)
2014-07-02 17:19 ` jmbnyc at gmail dot com
@ 2014-07-02 18:07 ` bugdal at aerifal dot cx
2014-07-02 18:18 ` jmbnyc at gmail dot com
` (19 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: bugdal at aerifal dot cx @ 2014-07-02 18:07 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #21 from Rich Felker <bugdal at aerifal dot cx> ---
Judging from the description, I suspect this is just a bug in your code (lack
of synchronization when accessing data read/written by other threads) and
neither a glibc bug nor a gcc bug. An "outline of the code" is definitely not
sufficient to determine this since the potential bug is in the details. A
minimal self-contained reproducible test case is needed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (25 preceding siblings ...)
2014-07-02 18:07 ` bugdal at aerifal dot cx
@ 2014-07-02 18:18 ` jmbnyc at gmail dot com
2014-07-03 3:13 ` andi-bz at firstfloor dot org
` (18 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: jmbnyc at gmail dot com @ 2014-07-02 18:18 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #22 from Jeffrey M. Birnbaum <jmbnyc at gmail dot com> ---
Well, I find that comment somewhat offensive, i.e. a bug in my code. I only
showed an outline so that you could comment on whether or not the trylock
elision issue was related to what I am observing.
I can certainly understand why you would say that given that a reproducible
test is the best proof of an issue. However, in your response you said "if you
have more information, please share" so that is what I did. I'm not sure I
deserved the "well, most likely a bug in your code where you don't sync
read/write properly".
Regardless, I will try to create a simple test case the repro's the issue. I
can assure you that there are no other variables involved in what I described
that come into play. In fact, the description is almost verbatim the code. The
only shared object is the pthread mutex and I think that was fairly clear from
the code snippet.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (26 preceding siblings ...)
2014-07-02 18:18 ` jmbnyc at gmail dot com
@ 2014-07-03 3:13 ` andi-bz at firstfloor dot org
2014-07-03 3:25 ` jmbnyc at gmail dot com
` (17 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: andi-bz at firstfloor dot org @ 2014-07-03 3:13 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Andi Kleen <andi-bz at firstfloor dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |FIXED
--- Comment #23 from Andi Kleen <andi-bz at firstfloor dot org> ---
Jeffrey,
If there's a problem it's not related to this bug. Please open a new bug.
Also to check for data races as Rich suggested please test your application
with valgrind/helgrind or ThreadSanitizer.
If there's still a problem a self contained test program would be useful.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (27 preceding siblings ...)
2014-07-03 3:13 ` andi-bz at firstfloor dot org
@ 2014-07-03 3:25 ` jmbnyc at gmail dot com
2014-07-03 16:51 ` schwab@linux-m68k.org
` (16 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: jmbnyc at gmail dot com @ 2014-07-03 3:25 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #24 from Jeffrey M. Birnbaum <jmbnyc at gmail dot com> ---
Thanks Andi.
I would like to create a simple test case (the code is certainly quite simple)
but it might be hard to "make it happen" without additional scheduler pressure
(might have to manufacture). Also, I don't see it fail all of the time. And the
odd thing is that when it fails, it will fail continuously. I wonder if it
might be code alignment issue where depending on how stuff is arranged I get
fail or no fail. Lastly, more evidence is that the only system the code fails
on is glibc 2.18 plus Haswell. Can't seem to repro on various other machines
(ivy and sandy).
Regardless, I will work on a test case because I know what I observe is a
scenario where try_lock fails in the case where another thread had the lock and
then released it.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (28 preceding siblings ...)
2014-07-03 3:25 ` jmbnyc at gmail dot com
@ 2014-07-03 16:51 ` schwab@linux-m68k.org
2014-07-21 20:43 ` cvs-commit at gcc dot gnu.org
` (15 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: schwab@linux-m68k.org @ 2014-07-03 16:51 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #25 from Andreas Schwab <schwab@linux-m68k.org> ---
Do not close this bug until it is fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (29 preceding siblings ...)
2014-07-03 16:51 ` schwab@linux-m68k.org
@ 2014-07-21 20:43 ` cvs-commit at gcc dot gnu.org
2014-08-19 0:36 ` cvs-commit at gcc dot gnu.org
` (14 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-07-21 20:43 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #26 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, azanella/lockelision-ppc has been created
at 58c786666e06b4d31f6d69ba846d2302e4f5af4c (commit)
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=58c786666e06b4d31f6d69ba846d2302e4f5af4c
commit 58c786666e06b4d31f6d69ba846d2302e4f5af4c
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Jun 25 15:13:46 2014 -0400
PowerPC: Add adaptive elision to rwlocks
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=afc0f998d1840d3239ed794cd58b771a4287eb28
commit afc0f998d1840d3239ed794cd58b771a4287eb28
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Mar 21 08:26:59 2014 -0400
PowerPC: Adjusting LE mutex destroy
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e47e7d86ac678ee4293da4295198a7eb45ecef01
commit e47e7d86ac678ee4293da4295198a7eb45ecef01
Author: Andreas Schwab <schwab@suse.de>
Date: Thu Mar 27 16:50:04 2014 -0400
Skip checks in pthread_mutex_destroy when doing elision
When doing elisison the __nusers field is not updated, thus can have an
arbitrary value.
[BZ #16657]
* nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy): Skip
checks when doing elision.
* nptl/sysdeps/unix/sysv/linux/x86/pthread_mutex_destroy.c: New
* file.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=552210e08eff6b757356dfc120c05ec1417179ef
commit 552210e08eff6b757356dfc120c05ec1417179ef
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Dec 13 15:59:35 2013 -0500
PowerPC: Add the low level infrastructure for pthreads lock elision
-----------------------------------------------------------------------
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (30 preceding siblings ...)
2014-07-21 20:43 ` cvs-commit at gcc dot gnu.org
@ 2014-08-19 0:36 ` cvs-commit at gcc dot gnu.org
2014-08-22 11:52 ` cvs-commit at gcc dot gnu.org
` (13 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-08-19 0:36 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #27 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, azanella/lockelision-ppc has been created
at 01f9a2bfda7e99ed3a95250a24b7bf45c25bca94 (commit)
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=01f9a2bfda7e99ed3a95250a24b7bf45c25bca94
commit 01f9a2bfda7e99ed3a95250a24b7bf45c25bca94
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Mon Aug 18 17:34:00 2014 -0400
powerpc32 fixes
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=558b909b2189cc79292fb719134b26565b10cd46
commit 558b909b2189cc79292fb719134b26565b10cd46
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Jun 25 15:13:46 2014 -0400
PowerPC: Add adaptive elision to rwlocks
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=3b5afff081da3beb1a047b9face01e9426327c05
commit 3b5afff081da3beb1a047b9face01e9426327c05
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Mar 21 08:26:59 2014 -0400
PowerPC: Adjusting LE mutex destroy
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e6c831927e22129641abaf09aff278584937f448
commit e6c831927e22129641abaf09aff278584937f448
Author: Andreas Schwab <schwab@suse.de>
Date: Thu Mar 27 16:50:04 2014 -0400
Skip checks in pthread_mutex_destroy when doing elision
When doing elisison the __nusers field is not updated, thus can have an
arbitrary value.
[BZ #16657]
* nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy): Skip
checks when doing elision.
* nptl/sysdeps/unix/sysv/linux/x86/pthread_mutex_destroy.c: New
* file.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c3f96a10ee7cb19af1dcc9353e3a52ddebd8c87b
commit c3f96a10ee7cb19af1dcc9353e3a52ddebd8c87b
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Dec 13 15:59:35 2013 -0500
PowerPC: Add the low level infrastructure for pthreads lock elision
-----------------------------------------------------------------------
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (31 preceding siblings ...)
2014-08-19 0:36 ` cvs-commit at gcc dot gnu.org
@ 2014-08-22 11:52 ` cvs-commit at gcc dot gnu.org
2014-08-25 13:05 ` cvs-commit at gcc dot gnu.org
` (12 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-08-22 11:52 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #28 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, azanella/lockelision-ppc has been created
at 412d804e06543203a31c06988a809e7c88d06b2b (commit)
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=412d804e06543203a31c06988a809e7c88d06b2b
commit 412d804e06543203a31c06988a809e7c88d06b2b
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Aug 20 15:50:58 2014 -0400
PowerPC: abort transaction in syscalls
Linux kernel powerpc documentation states issuing a syscall inside a
transaction is not recommended and may lead to undefined behavior. It
also states syscalls does not abort transactoin neither they run in
transactional state.
To avoid side-effects bein visible outside transactions, GLIBC with lock
elision enable issues a transaction abort instruction just before all
syscalls if hardware supports hardware transactions.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=25a5dad5f14f747577a5cffeafcd8bd5a52b31bf
commit 25a5dad5f14f747577a5cffeafcd8bd5a52b31bf
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Jun 25 15:13:46 2014 -0400
PowerPC: Add adaptive elision to rwlocks
This patch adds support for lock elision using ISA 2.07 hardware
transactional memory for rwlocks.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=00702011fff76cc94517889874359486995ef098
commit 00702011fff76cc94517889874359486995ef098
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Mar 21 08:26:59 2014 -0400
PowerPC: Adjusting LE mutex destroy
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5421cda51f0c177cad1757dd69b9319a1db7155c
commit 5421cda51f0c177cad1757dd69b9319a1db7155c
Author: Andreas Schwab <schwab@suse.de>
Date: Thu Mar 27 16:50:04 2014 -0400
Skip checks in pthread_mutex_destroy when doing elision
When doing elisison the __nusers field is not updated, thus can have an
arbitrary value.
[BZ #16657]
* nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy): Skip
checks when doing elision.
* nptl/sysdeps/unix/sysv/linux/x86/pthread_mutex_destroy.c: New
* file.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d3f269d75a82389717ddf041edadb0d4f8459dba
commit d3f269d75a82389717ddf041edadb0d4f8459dba
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Aug 20 15:57:10 2014 -0400
PowerPC: Add the low level infrastructure for pthreads lock elision
This patch adds support for lock elision using ISA 2.07 hardware
transactional memory instructions.
-----------------------------------------------------------------------
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (32 preceding siblings ...)
2014-08-22 11:52 ` cvs-commit at gcc dot gnu.org
@ 2014-08-25 13:05 ` cvs-commit at gcc dot gnu.org
2014-08-25 13:10 ` azanella at linux dot vnet.ibm.com
` (11 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-08-25 13:05 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #29 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, azanella/lockelision-ppc has been created
at 60027c63e2110612cd3b05a32c89c299a8e20a3a (commit)
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=60027c63e2110612cd3b05a32c89c299a8e20a3a
commit 60027c63e2110612cd3b05a32c89c299a8e20a3a
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Aug 20 15:50:58 2014 -0400
PowerPC: abort transaction in syscalls
Linux kernel powerpc documentation states issuing a syscall inside a
transaction is not recommended and may lead to undefined behavior. It
also states syscalls does not abort transactoin neither they run in
transactional state.
To avoid side-effects being visible outside transactions, GLIBC with lock
elision enable issues a transaction abort instruction just before all
syscalls if hardware supports hardware transactions.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f173d8d0dfb557c50c5d8bf26755716a444e2e0d
commit f173d8d0dfb557c50c5d8bf26755716a444e2e0d
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Jun 25 15:13:46 2014 -0400
PowerPC: Add adaptive elision to rwlocks
This patch adds support for lock elision using ISA 2.07 hardware
transactional memory for rwlocks.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=1fef4f021fe32317095e2bf936d54d530290d055
commit 1fef4f021fe32317095e2bf936d54d530290d055
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Mar 21 08:26:59 2014 -0400
PowerPC: Adjusting LE mutex destroy
This patch adjust the pthread_mutex_t destroy to take acocunt of lock
elision.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=29e18b25d1b574bcaeb7422ec8b103e3463ba7b4
commit 29e18b25d1b574bcaeb7422ec8b103e3463ba7b4
Author: Andreas Schwab <schwab@suse.de>
Date: Thu Mar 27 16:50:04 2014 -0400
Skip checks in pthread_mutex_destroy when doing elision
When doing elisison the __nusers field is not updated, thus can have an
arbitrary value.
[BZ #16657]
* nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy): Skip
checks when doing elision.
* nptl/sysdeps/unix/sysv/linux/x86/pthread_mutex_destroy.c: New
* file.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=247cf3825e280047de915f3dab767cae02c7cf98
commit 247cf3825e280047de915f3dab767cae02c7cf98
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Aug 20 15:57:10 2014 -0400
PowerPC: Add the low level infrastructure for pthreads lock elision
This patch adds support for lock elision using ISA 2.07 hardware
transactional memory instructions.
-----------------------------------------------------------------------
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (33 preceding siblings ...)
2014-08-25 13:05 ` cvs-commit at gcc dot gnu.org
@ 2014-08-25 13:10 ` azanella at linux dot vnet.ibm.com
2014-10-01 18:43 ` carlos at redhat dot com
` (10 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: azanella at linux dot vnet.ibm.com @ 2014-08-25 13:10 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Adhemerval Zanella Netto <azanella at linux dot vnet.ibm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |azanella at linux dot vnet.ibm.com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (34 preceding siblings ...)
2014-08-25 13:10 ` azanella at linux dot vnet.ibm.com
@ 2014-10-01 18:43 ` carlos at redhat dot com
2014-10-01 20:49 ` schwab@linux-m68k.org
` (9 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: carlos at redhat dot com @ 2014-10-01 18:43 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #30 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Andreas Schwab from comment #25)
> Do not close this bug until it is fixed.
Is this fixed yet?
commit e47e7d86ac678ee4293da4295198a7eb45ecef01
Author: Andreas Schwab <schwab@suse.de>
Date: Thu Mar 27 16:50:04 2014 -0400
Skip checks in pthread_mutex_destroy when doing elision
When doing elisison the __nusers field is not updated, thus can have an
arbitrary value.
[BZ #16657]
* nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy): Skip
checks when doing elision.
* nptl/sysdeps/unix/sysv/linux/x86/pthread_mutex_destroy.c: New
* file.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (35 preceding siblings ...)
2014-10-01 18:43 ` carlos at redhat dot com
@ 2014-10-01 20:49 ` schwab@linux-m68k.org
2014-10-01 21:00 ` carlos at redhat dot com
` (8 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: schwab@linux-m68k.org @ 2014-10-01 20:49 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #31 from Andreas Schwab <schwab@linux-m68k.org> ---
http://sourceware.org/git/?p=glibc.git;a=commit;h=e47e7d86ac678ee4293da4295198a7eb45ecef01
404 - Unknown commit object
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (36 preceding siblings ...)
2014-10-01 20:49 ` schwab@linux-m68k.org
@ 2014-10-01 21:00 ` carlos at redhat dot com
2014-10-01 21:04 ` azanella at linux dot vnet.ibm.com
` (7 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: carlos at redhat dot com @ 2014-10-01 21:00 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #32 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Andreas Schwab from comment #31)
> http://sourceware.org/git/?p=glibc.git;a=commit;
> h=e47e7d86ac678ee4293da4295198a7eb45ecef01
>
> 404 - Unknown commit object
It's on the private IBM branch. The question is, do you think that fixes the
issue? Does it need review?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (37 preceding siblings ...)
2014-10-01 21:00 ` carlos at redhat dot com
@ 2014-10-01 21:04 ` azanella at linux dot vnet.ibm.com
2014-10-02 14:02 ` schwab@linux-m68k.org
` (6 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: azanella at linux dot vnet.ibm.com @ 2014-10-01 21:04 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #33 from Adhemerval Zanella Netto <azanella at linux dot vnet.ibm.com> ---
Some disclaimer: I think the link came from my TLE port for PowerPC. I had
included this patch because I thought it could help some issue in my port that
was not really arising from this bugzilla in particular.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (38 preceding siblings ...)
2014-10-01 21:04 ` azanella at linux dot vnet.ibm.com
@ 2014-10-02 14:02 ` schwab@linux-m68k.org
2014-11-07 17:06 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: schwab@linux-m68k.org @ 2014-10-02 14:02 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #34 from Andreas Schwab <schwab@linux-m68k.org> ---
https://sourceware.org/ml/libc-alpha/2014-09/msg00218.html
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (39 preceding siblings ...)
2014-10-02 14:02 ` schwab@linux-m68k.org
@ 2014-11-07 17:06 ` cvs-commit at gcc dot gnu.org
2014-12-11 11:45 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-11-07 17:06 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #35 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, azanella/lockelision-ppc has been created
at 9fba46fff61c04bb1ec8bec9ab51202ee6e1b2e4 (commit)
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9fba46fff61c04bb1ec8bec9ab51202ee6e1b2e4
commit 9fba46fff61c04bb1ec8bec9ab51202ee6e1b2e4
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Aug 20 15:50:58 2014 -0400
PowerPC: abort transaction in syscalls
Linux kernel powerpc documentation states issuing a syscall inside a
transaction is not recommended and may lead to undefined behavior. It
also states syscalls does not abort transactoin neither they run in
transactional state.
To avoid side-effects being visible outside transactions, GLIBC with lock
elision enable issues a transaction abort instruction just before all
syscalls if hardware supports hardware transactions.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7cb8358e83af829ba2756182d7d5a25ebb292fac
commit 7cb8358e83af829ba2756182d7d5a25ebb292fac
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Jun 25 15:13:46 2014 -0400
PowerPC: Add adaptive elision to rwlocks
This patch adds support for lock elision using ISA 2.07 hardware
transactional memory for rwlocks.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=486e99da18df01e8cabbcaa578fcb6402c479a54
commit 486e99da18df01e8cabbcaa578fcb6402c479a54
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Fri Mar 21 08:26:59 2014 -0400
PowerPC: Adjusting LE mutex destroy
This patch adjust the pthread_mutex_t destroy to take acocunt of lock
elision.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f4335e87a7d5e2339123fbeaa0ef2f8f7797e6d4
commit f4335e87a7d5e2339123fbeaa0ef2f8f7797e6d4
Author: Andreas Schwab <schwab@suse.de>
Date: Thu Mar 27 16:50:04 2014 -0400
Skip checks in pthread_mutex_destroy when doing elision
When doing elisison the __nusers field is not updated, thus can have an
arbitrary value.
[BZ #16657]
* nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy): Skip
checks when doing elision.
* nptl/sysdeps/unix/sysv/linux/x86/pthread_mutex_destroy.c: New
* file.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=585a5fbda268d5ed265c5ecd81607c54864471ca
commit 585a5fbda268d5ed265c5ecd81607c54864471ca
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date: Wed Aug 20 15:57:10 2014 -0400
PowerPC: Add the low level infrastructure for pthreads lock elision
This patch adds support for lock elision using ISA 2.07 hardware
transactional memory instructions.
-----------------------------------------------------------------------
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (40 preceding siblings ...)
2014-11-07 17:06 ` cvs-commit at gcc dot gnu.org
@ 2014-12-11 11:45 ` cvs-commit at gcc dot gnu.org
2014-12-11 11:48 ` schwab@linux-m68k.org
` (3 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-12-11 11:45 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #36 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 b0a3c1640ab2fb7d16d9b9a8d9c0e524e9cb0001 (commit)
from da5bcaa49916fd99c1cd2bfe11923e680056abd7 (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=b0a3c1640ab2fb7d16d9b9a8d9c0e524e9cb0001
commit b0a3c1640ab2fb7d16d9b9a8d9c0e524e9cb0001
Author: Andreas Schwab <schwab@suse.de>
Date: Tue Mar 4 13:00:26 2014 +0100
Properly handle forced elision in pthread_mutex_trylock (bug 16657)
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 8 ++++++++
NEWS | 10 +++++-----
nptl/pthread_mutex_trylock.c | 9 ++++-----
sysdeps/unix/sysv/linux/s390/force-elision.h | 5 -----
sysdeps/unix/sysv/linux/x86/force-elision.h | 5 -----
5 files changed, 17 insertions(+), 20 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (41 preceding siblings ...)
2014-12-11 11:45 ` cvs-commit at gcc dot gnu.org
@ 2014-12-11 11:48 ` schwab@linux-m68k.org
2014-12-11 11:48 ` schwab@linux-m68k.org
` (2 subsequent siblings)
45 siblings, 0 replies; 47+ messages in thread
From: schwab@linux-m68k.org @ 2014-12-11 11:48 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2.21
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (42 preceding siblings ...)
2014-12-11 11:48 ` schwab@linux-m68k.org
@ 2014-12-11 11:48 ` schwab@linux-m68k.org
2015-02-18 14:45 ` fweimer at redhat dot com
2015-08-28 20:43 ` cvs-commit at gcc dot gnu.org
45 siblings, 0 replies; 47+ messages in thread
From: schwab@linux-m68k.org @ 2014-12-11 11:48 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |FIXED
--- Comment #37 from Andreas Schwab <schwab@linux-m68k.org> ---
Fixed in 2.21.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (43 preceding siblings ...)
2014-12-11 11:48 ` schwab@linux-m68k.org
@ 2015-02-18 14:45 ` fweimer at redhat dot com
2015-08-28 20:43 ` cvs-commit at gcc dot gnu.org
45 siblings, 0 replies; 47+ messages in thread
From: fweimer at redhat dot com @ 2015-02-18 14:45 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--- Comment #39 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Florian Weimer from comment #14)
> (In reply to Rich Felker from comment #13)
> > Yes, see comment #5. But if you're asking about security flag, my impression
> > was that so far the security flag is only being used where the bug leads
> > directly to a security problem more serious than plain DoS.
>
> I was asking about real-world application impact, e.g. "we discovered this
> bug because Apache httpd was crashing after processing a certain sequence of
> requests" (purely hypothetically speaking). It's not always easy to draw
> the line between a reliability bug which manifests somewhat randomly, and a
> denial-of-service vulnerability which can be triggered with some
> non-negligible probability (which will approach 1 after a sufficient number
> of attempts).
No security impact has been reported, so I'm flagging this as security-.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread* [Bug nptl/16657] Lock elision breaks pthread_mutex_destroy
2014-03-04 9:07 [Bug nptl/16657] New: Lock elision breaks pthread_mutex_trylock schwab@linux-m68k.org
` (44 preceding siblings ...)
2015-02-18 14:45 ` fweimer at redhat dot com
@ 2015-08-28 20:43 ` cvs-commit at gcc dot gnu.org
45 siblings, 0 replies; 47+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2015-08-28 20:43 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16657
--- Comment #40 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, release/2.19/master has been updated
via 323e41a8d8168dac0338bf95c12a8de5b0dfc56e (commit)
from 980a63b384df3086b2969b9f7e8dd2f016caa78c (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=323e41a8d8168dac0338bf95c12a8de5b0dfc56e
commit 323e41a8d8168dac0338bf95c12a8de5b0dfc56e
Author: Andreas Schwab <schwab@suse.de>
Date: Tue Mar 4 13:00:26 2014 +0100
Properly handle forced elision in pthread_mutex_trylock (bug 16657)
(cherry picked from commit b0a3c1640ab2fb7d16d9b9a8d9c0e524e9cb0001)
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 8 ++++++++
NEWS | 4 ++--
nptl/pthread_mutex_trylock.c | 9 ++++-----
nptl/sysdeps/unix/sysv/linux/x86/force-elision.h | 5 -----
4 files changed, 14 insertions(+), 12 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 47+ messages in thread