[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