[PATCH] malloc: Run fork handler as late as possible [BZ #19431]
Florian Weimer
fweimer@redhat.com
Wed Feb 10 21:44:00 GMT 2016
Previously, a thread M invoking fork would acquire locks in this order:
(M1) malloc arena locks (in the registered fork handler)
(M2) libio list lock
A thread F invoking flush (NULL) would acquire locks in this order:
(F1) libio list lock
(F2) individual _IO_FILE locks
A thread G running getdelim would use this order:
(G1) _IO_FILE lock
(G2) malloc arena lock
After executing (M1), (F1), (G1), none of the threads can make progress.
This commit changes the fork lock order to:
(M'1) libio list lock
(M'2) malloc arena locks
It explicitly encodes the lock order in the implementations of fork,
and does not rely on the registration order, thus avoiding the deadlock.
I couldn't test the Hurd bits, but the changes look straightforward enough.
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-malloc-Run-fork-handler-as-late-as-possible-BZ-19431.patch
Type: text/x-patch
Size: 16898 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160210/b83d6028/attachment.bin>
More information about the Libc-alpha
mailing list