Linux quote Kernel programming
<<There's a different issue with freeing of mutexes, which is not a bug,
but "by design". Namely that mutexes aren't truly "atomic". They are
complex data structures, and they have issues that a spinlock does not
have.
When unlocking a mutex, the thread doing the unlocking will still
touch the mutex itself
after another thread could already have
successfully acquired the mutex. This is not a problem in any normal
use. since all of this is perfectly coherent in general, but it means
that code sequences like:
mutex_lock(mem->mutex);
kill_it = !--mem->refcount;
mutex_unlock(mem->mutex);
if (kill_it)
free(mem);
are fundamentally buggy.
Note that if you think of mutexes as truly indivisible atomic
operations, the above is "obviously correct": the last person who got
the mutex marked it for killing. But the fact is, the
next-to-last
mutex acquirer may still actively be in the
non-indivisible
mutex_unlock() when the last person frees it, resulting in a
use-after-free. And yes, we've had this bug, and as far as I know it's
possible that the RT code
introduces this bug when it changes
spinlocks into mutexes. Because we do exactly the above code sequence
with spinlocks. So just replacing spinlocks with mutexes is a very
subtly buggy thing to do in general.
>
from Linus Torvalds
lkml.org
