.The `fork` function avoids certain deadlocks related to use of `pthread_atfork`
Previously, if a program registered an `atfork` handler and invoked `fork` from an asynchronous-signal handler, a defect in the internal implementation-dependent lock could cause the program to freeze. With this update, the implementation of `fork` and its `atfork` handlers is adjusted to avoid the deadlock in single-threaded programs.
We should backport this upstream regression fix, to avoid impacting applications:
commit 669ff911e2571f74a2668493e326ac9a505776bd
Author: Florian Weimer <fweimer>
Date: Fri Feb 8 12:46:19 2019 +0100
nptl: Avoid fork handler lock for async-signal-safe fork [BZ #24161]
Commit 27761a1042daf01987e7d79636d0c41511c6df3c ("Refactor atfork
handlers") introduced a lock, atfork_lock, around fork handler list
accesses. It turns out that this lock occasionally results in
self-deadlocks in malloc/tst-mallocfork2:
(gdb) bt
#0 __lll_lock_wait_private ()
at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:63
#1 0x00007f160c6f927a in __run_fork_handlers (who=(unknown: 209394016),
who@entry=atfork_run_prepare) at register-atfork.c:116
#2 0x00007f160c6b7897 in __libc_fork () at ../sysdeps/nptl/fork.c:58
#3 0x00000000004027d6 in sigusr1_handler (signo=<optimized out>)
at tst-mallocfork2.c:80
#4 sigusr1_handler (signo=<optimized out>) at tst-mallocfork2.c:64
#5 <signal handler called>
#6 0x00007f160c6f92e4 in __run_fork_handlers (who=who@entry=atfork_run_parent)
at register-atfork.c:136
#7 0x00007f160c6b79a2 in __libc_fork () at ../sysdeps/nptl/fork.c:152
#8 0x0000000000402567 in do_test () at tst-mallocfork2.c:156
#9 0x0000000000402dd2 in support_test_main (argc=1, argv=0x7ffc81ef1ab0,
config=config@entry=0x7ffc81ef1970) at support_test_main.c:350
#10 0x0000000000402362 in main (argc=<optimized out>, argv=<optimized out>)
at ../support/test-driver.c:168
If no locking happens in the single-threaded case (where fork is
expected to be async-signal-safe), this deadlock is avoided.
(pthread_atfork is not required to be async-signal-safe, so a fork
call from a signal handler interrupting pthread_atfork is not
a problem.)
The problematic commit went into 2.28 and is therefore included in Red Hat Enterprise Linux 8.
Please also verify upstream branch backports:
release/2.30/master - May be required. Please check.
release/2.29/master - May be required. Please check.
release/2.28/master - May be required. Please check.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2020:1828
We should backport this upstream regression fix, to avoid impacting applications: commit 669ff911e2571f74a2668493e326ac9a505776bd Author: Florian Weimer <fweimer> Date: Fri Feb 8 12:46:19 2019 +0100 nptl: Avoid fork handler lock for async-signal-safe fork [BZ #24161] Commit 27761a1042daf01987e7d79636d0c41511c6df3c ("Refactor atfork handlers") introduced a lock, atfork_lock, around fork handler list accesses. It turns out that this lock occasionally results in self-deadlocks in malloc/tst-mallocfork2: (gdb) bt #0 __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:63 #1 0x00007f160c6f927a in __run_fork_handlers (who=(unknown: 209394016), who@entry=atfork_run_prepare) at register-atfork.c:116 #2 0x00007f160c6b7897 in __libc_fork () at ../sysdeps/nptl/fork.c:58 #3 0x00000000004027d6 in sigusr1_handler (signo=<optimized out>) at tst-mallocfork2.c:80 #4 sigusr1_handler (signo=<optimized out>) at tst-mallocfork2.c:64 #5 <signal handler called> #6 0x00007f160c6f92e4 in __run_fork_handlers (who=who@entry=atfork_run_parent) at register-atfork.c:136 #7 0x00007f160c6b79a2 in __libc_fork () at ../sysdeps/nptl/fork.c:152 #8 0x0000000000402567 in do_test () at tst-mallocfork2.c:156 #9 0x0000000000402dd2 in support_test_main (argc=1, argv=0x7ffc81ef1ab0, config=config@entry=0x7ffc81ef1970) at support_test_main.c:350 #10 0x0000000000402362 in main (argc=<optimized out>, argv=<optimized out>) at ../support/test-driver.c:168 If no locking happens in the single-threaded case (where fork is expected to be async-signal-safe), this deadlock is avoided. (pthread_atfork is not required to be async-signal-safe, so a fork call from a signal handler interrupting pthread_atfork is not a problem.) The problematic commit went into 2.28 and is therefore included in Red Hat Enterprise Linux 8.