Bug 1746928

Summary: glibc: Avoid fork handler lock for async-signal-safe fork
Product: Red Hat Enterprise Linux 8 Reporter: Florian Weimer <fweimer>
Component: glibcAssignee: DJ Delorie <dj>
Status: CLOSED ERRATA QA Contact: qe-baseos-tools-bugs
Severity: medium Docs Contact: Zuzana Zoubkova <zzoubkov>
Priority: medium    
Version: 8.2CC: ashankar, codonell, dj, fweimer, mnewsome, pfrankli, skolosov
Target Milestone: rcKeywords: Patch, Triaged
Target Release: 8.0   
Hardware: All   
OS: Linux   
Fixed In Version: glibc-2.28-83 Doc Type: Bug Fix
Doc Text:
.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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 16:50:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1746918    

Description Florian Weimer 2019-08-29 14:16:22 UTC
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.

Comment 1 Carlos O'Donell 2019-10-22 14:04:02 UTC
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.

Comment 3 Sergey Kolosov 2020-03-29 19:45:08 UTC
Verified manually with gdb and a simplified test case based on tst-mallocfork2.

Comment 8 errata-xmlrpc 2020-04-28 16:50:14 UTC
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.