← All posts tagged programming

tzirechnoy

Компания Mozilla опубликовала финансовый отчёт за 2015 год (via linux.org.ru ): mozilla.org

Что меня действительно удивляет — как можно за пол-миллиарда баксов выпускать такое говно? Я дажэ не про "не стыдно", я про то, что там какой-то средний уровень проектирования фичей где-то похужэ комплекта user.exe+gdi.exe+vfw+opengl 1.2, а уж уровень реализацыи просто нижэ плинтуса.

tzirechnoy

< 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