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

--- Comment #18 from Rich Felker <bugdal at aerifal dot cx> 2012-03-07 17:52:03 UTC ---
You misunderstand the race.

Suppose thread A is unlocking the mutex and gets descheduled after the
atomic_exchange_rel but before the lll_futex_wake, and thread B is waiting to
lock the mutex. At this point, as far thread B can observe, A is no longer a
user of the mutex. Thread B obtains the mutex, performs some operations,
unlocks the mutex, and assuming (correctly) that it's now the last user of the
mutex, destroys it and frees the memory it occupied.

Now at some later point, thread A gets scheduled again and crashes accessing
freed memory.

If you're wondering how thread B could wake up without thread A calling
lll_futex_wake, here are several reasons:

1. Never going to sleep due to value mismatch on the original futex wait call.
2. Receipt of a signal, and value mismatch when the signal handler returns and
futex wait is called again.
3. Spurious wakes that look like successful returns from wait. These do exist
in Linux, and I have not been able to determine the reason, but I have a test
program which can successfully produce them in one case (unrelated to mutexes).

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]