Bug 1888660
Summary: | glibc: pthread_atfork handlers that call pthread_atfork deadlock | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Paulo Andrade <pandrade> | ||||
Component: | glibc | Assignee: | Arjun Shankar <ashankar> | ||||
Status: | CLOSED ERRATA | QA Contact: | Martin Coufal <mcoufal> | ||||
Severity: | medium | Docs Contact: | Jacob Taylor Valdez <jvaldez> | ||||
Priority: | unspecified | ||||||
Version: | 8.2 | CC: | ashankar, codonell, dj, fweimer, jvaldez, mcoufal, mnewsome, pfrankli, sipoyare, skolosov, vikpatil | ||||
Target Milestone: | rc | Keywords: | Bugfix, Patch, Triaged | ||||
Target Release: | 8.0 | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | glibc-2.28-206.el8 | Doc Type: | Bug Fix | ||||
Doc Text: |
.Applications no longer deadlock when invoking `pthread_atfork` or `dclose` from fork handler callbacks
Previously, applications invoked `pthread_atfork` handler callbacks while `glibc` had acquired an internal lock. As a result, registering fork handlers or calling `dclose` from a fork handler could deadlock applications.
A different synchronization mechanism is now used to protect internal data structures while fork handlers are running. As a result, applications no longer deadlock when invoking `pthread_atfork` or `dclose` from fork handler callbacks.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2022-11-08 10:43:11 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: | |||||
Embargoed: | |||||||
Deadline: | 2022-07-04 | ||||||
Attachments: |
|
Description
Paulo Andrade
2020-10-15 12:56:46 UTC
The problem is this: static void __attribute__((constructor)) init(void) { pthread_atfork(NULL, NULL, init); } This recursive call into the fork subsystem now deadlocks. An upstream patch has been posted: https://sourceware.org/bugzilla/show_bug.cgi?id=24595#c1 There were some concerns about this patch. The key point will be not to call any callback functions while implementation locks are held. With glibc, re-registering fork handlers after fork (in the subprocess) is not necessary because they are automatically inherited. This is likely not POSIX-compliant, but is long-standing glibc behavior, and it cannot be changed. So as a workaround, you can change this: static void __attribute__((constructor)) init(void) { pthread_atfork(NULL, NULL, init); } to: static void handler(void) { // Real fork handler here. } static void __attribute__((constructor)) init(void) { pthread_atfork(NULL, NULL, handler); } Patches for this are now under review upstream: https://patchwork.sourceware.org/project/glibc/patch/20220427134625.3759831-1-arjun@redhat.com/ 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 (glibc bug fix and enhancement update), 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/RHBA-2022:7684 |