This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
             Status|ASSIGNED                    |WAITING
                 CC|                            |drepper.fsp at gmail dot
                   |                            |com

--- Comment #17 from Ulrich Drepper <drepper.fsp at gmail dot com> 2012-03-07 10:29:21 UTC ---
(In reply to comment #0)
> 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.

You read the code incorrectly.

If B is reached there must be another thread using the mutex.  It is currently
waiting.  In that case it is invalid to destroy the mutex.  In any case would
there be another memory access, from the thread which is woken by the
lll_futex_wake call.

The same applies to whatever you try to change with your patch.

Again, as long as a thread is waiting on a mutex you cannot destroy it legally.
 Show me a place where the code is accessing the futex after the unlock when
there is no locker.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]