]> git.ipfire.org Git - thirdparty/glibc.git/commit
malloc: Run fork handler as late as possible [BZ #19431]
authorFlorian Weimer <fweimer@redhat.com>
Thu, 14 Apr 2016 07:17:02 +0000 (09:17 +0200)
committerFlorian Weimer <fweimer@redhat.com>
Mon, 9 May 2016 09:22:00 +0000 (11:22 +0200)
commit2a71cf409681b89ffb8892b35cac64de79b7adb8
treea9cdc8bc5646f8a9f694f63773322c50e0732bd7
parenta5c2f42566460fc73755c768e8e1c59dbd5a4bb2
malloc: Run fork handler as late as possible [BZ #19431]

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.

(cherry picked from commit 29d794863cd6e03115d3670707cc873a9965ba92)
ChangeLog
malloc/Makefile
malloc/arena.c
malloc/malloc-internal.h [new file with mode: 0644]
malloc/malloc.c
malloc/tst-malloc-fork-deadlock.c [new file with mode: 0644]
manual/memory.texi
sysdeps/mach/hurd/fork.c
sysdeps/nptl/fork.c