This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access
- From: "carlos at systemhalted dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Fri, 17 Feb 2012 16:36:54 +0000
- Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access
- Auto-submitted: auto-generated
- References: <bug-13690-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13690
Carlos O'Donell <carlos at systemhalted dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at redhat dot com
--- Comment #14 from Carlos O'Donell <carlos at systemhalted dot org> 2012-02-17 16:36:54 UTC ---
Nemoto-san,
The patch looks good to me.
My only worry is that the performance of the robust unlock fast path is
impacted.
I notice that PTHREAD_ROBUST_MUTEX_PSHARED always returns LLL_SHARED.
Therefore it would be optimal if instead of a temporary we just passed down
LLL_SHARED (a constant).
I don't know why glibc has the PTHREAD_ROBUST_MUTEX_PSHARED macro.
The code comment says:
~~~
/* The kernel when waking robust mutexes on exit never uses
FUTEX_PRIVATE_FLAG FUTEX_WAKE. */
#define PTHREAD_ROBUST_MUTEX_PSHARED(m) LLL_SHARED
~~~
Which appears to imply that at some point in the future it might not always
return LLL_SHARED.
Therefore your patch is correct.
Can you verify that the instruction sequences generated are identical given the
optimization level -O2 used to compile glibc?
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.