* pthread_mutex_unlock potentially cause invalid access
@ 2012-02-10 14:43 Atsushi Nemoto
2012-02-10 21:16 ` Roland McGrath
0 siblings, 1 reply; 3+ messages in thread
From: Atsushi Nemoto @ 2012-02-10 14:43 UTC (permalink / raw)
To: libc-alpha, libc-ports
It seems pthread_mutex_unlock() potentially cause invalid access on
most platforms (except for i386 and x86_64).
# Resend with correct ML address. Excuse me for duplication.
In nptl/pthread_mutex_unlock.c, lll_unlock() is called like this:
lll_unlock (mutex->__data.__lock, PTHREAD_MUTEX_PSHARED (mutex));
And PTHREAD_MUTEX_PSHARED() is defined like this:
# define PTHREAD_MUTEX_PSHARED(m) \
((m)->__data.__kind & 128)
On most platforms, lll_unlock() is defined as a macro like this:
#define lll_unlock(lock, private) \
((void) ({ \
int *__futex = &(lock); \
int __val = atomic_exchange_rel (__futex, 0); \
if (__builtin_expect (__val > 1, 0)) \
lll_futex_wake (__futex, 1, private); \
}))
Thus, the lll_unlock() call in pthread_mutex_unlock.c will be expanded as:
int *__futex = &(mutex->__data.__lock);
int __val = atomic_exchange_rel (__futex, 0);
if (__builtin_expect (__val > 1, 0)) /* A */
lll_futex_wake (__futex, 1, ((mutex)->__data.__kind & 128)); /* B */
On point "A", the mutex is actually unlocked, so other threads can
lock the mutex, unlock, destroy and free. If the mutex was destroyed
and freed by other thread, reading '__kind' on point "B" is not valid.
Possible fix would be copying the 'private' argument to an internal
local variable before atomic_exchange_rel(). Is it an appropriate fix?
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 3+ messages in thread
* pthread_mutex_unlock potentially cause invalid access
@ 2012-02-10 14:28 Atsushi Nemoto
0 siblings, 0 replies; 3+ messages in thread
From: Atsushi Nemoto @ 2012-02-10 14:28 UTC (permalink / raw)
To: libc-alpha, libc-ports
It seems pthread_mutex_unlock() potentially cause invalid access on
most platforms (except for i386 and x86_64).
In nptl/pthread_mutex_unlock.c, lll_unlock() is called like this:
lll_unlock (mutex->__data.__lock, PTHREAD_MUTEX_PSHARED (mutex));
And PTHREAD_MUTEX_PSHARED() is defined like this:
# define PTHREAD_MUTEX_PSHARED(m) \
((m)->__data.__kind & 128)
On most platforms, lll_unlock() is defined as a macro like this:
#define lll_unlock(lock, private) \
((void) ({ \
int *__futex = &(lock); \
int __val = atomic_exchange_rel (__futex, 0); \
if (__builtin_expect (__val > 1, 0)) \
lll_futex_wake (__futex, 1, private); \
}))
Thus, the lll_unlock() call in pthread_mutex_unlock.c will be expanded as:
int *__futex = &(mutex->__data.__lock);
int __val = atomic_exchange_rel (__futex, 0);
if (__builtin_expect (__val > 1, 0)) /* A */
lll_futex_wake (__futex, 1, ((mutex)->__data.__kind & 128)); /* B */
On point "A", the mutex is actually unlocked, so other threads can
lock the mutex, unlock, destroy and free. If the mutex was destroyed
and freed by other thread, reading '__kind' on point "B" is not valid.
Possible fix would be copying the 'private' argument to an internal
local variable before atomic_exchange_rel(). Is it an appropriate fix?
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-02-10 21:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-10 14:43 pthread_mutex_unlock potentially cause invalid access Atsushi Nemoto
2012-02-10 21:16 ` Roland McGrath
-- strict thread matches above, loose matches on Subject: below --
2012-02-10 14:28 Atsushi Nemoto
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).