Some applications call pthread_atfork from a pthread_atfork handler in the new subprocess because POSIX does not specify that the handlers are duplicated by fork. With the current implementation, this results in a deadlock. We must not call pthread_atfork handlers while holding implementation locks.
Would it be a duplicate of BZ#24595?
Definitely related, but that really depends on how the bugs are fixed.
The master branch has been updated by Arjun Shankar <arjun@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=52a103e237329b9f88a28513fe7506ffc3bd8ced commit 52a103e237329b9f88a28513fe7506ffc3bd8ced Author: Arjun Shankar <arjun@redhat.com> Date: Tue May 24 17:57:36 2022 +0200 Fix deadlock when pthread_atfork handler calls pthread_atfork or dlclose In multi-threaded programs, registering via pthread_atfork, de-registering implicitly via dlclose, or running pthread_atfork handlers during fork was protected by an internal lock. This meant that a pthread_atfork handler attempting to register another handler or dlclose a dynamically loaded library would lead to a deadlock. This commit fixes the deadlock in the following way: During the execution of handlers at fork time, the atfork lock is released prior to the execution of each handler and taken again upon its return. Any handler registrations or de-registrations that occurred during the execution of the handler are accounted for before proceeding with further handler execution. If a handler that hasn't been executed yet gets de-registered by another handler during fork, it will not be executed. If a handler gets registered by another handler during fork, it will not be executed during that particular fork. The possibility that handlers may now be registered or deregistered during handler execution means that identifying the next handler to be run after a given handler may register/de-register others requires some bookkeeping. The fork_handler struct has an additional field, 'id', which is assigned sequentially during registration. Thus, handlers are executed in ascending order of 'id' during 'prepare', and descending order of 'id' during parent/child handler execution after the fork. Two tests are included: * tst-atfork3: Adhemerval Zanella <adhemerval.zanella@linaro.org> This test exercises calling dlclose from prepare, parent, and child handlers. * tst-atfork4: This test exercises calling pthread_atfork and dlclose from the prepare handler. [BZ #24595, BZ #27054] Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The release/2.35/master branch has been updated by Arjun Shankar <arjun@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6abb4002df97df668f40b0da84ab6261498a8541 commit 6abb4002df97df668f40b0da84ab6261498a8541 Author: Arjun Shankar <arjun@redhat.com> Date: Tue May 24 17:57:36 2022 +0200 Fix deadlock when pthread_atfork handler calls pthread_atfork or dlclose In multi-threaded programs, registering via pthread_atfork, de-registering implicitly via dlclose, or running pthread_atfork handlers during fork was protected by an internal lock. This meant that a pthread_atfork handler attempting to register another handler or dlclose a dynamically loaded library would lead to a deadlock. This commit fixes the deadlock in the following way: During the execution of handlers at fork time, the atfork lock is released prior to the execution of each handler and taken again upon its return. Any handler registrations or de-registrations that occurred during the execution of the handler are accounted for before proceeding with further handler execution. If a handler that hasn't been executed yet gets de-registered by another handler during fork, it will not be executed. If a handler gets registered by another handler during fork, it will not be executed during that particular fork. The possibility that handlers may now be registered or deregistered during handler execution means that identifying the next handler to be run after a given handler may register/de-register others requires some bookkeeping. The fork_handler struct has an additional field, 'id', which is assigned sequentially during registration. Thus, handlers are executed in ascending order of 'id' during 'prepare', and descending order of 'id' during parent/child handler execution after the fork. Two tests are included: * tst-atfork3: Adhemerval Zanella <adhemerval.zanella@linaro.org> This test exercises calling dlclose from prepare, parent, and child handlers. * tst-atfork4: This test exercises calling pthread_atfork and dlclose from the prepare handler. [BZ #24595, BZ #27054] Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 52a103e237329b9f88a28513fe7506ffc3bd8ced)
The release/2.34/master branch has been updated by Arjun Shankar <arjun@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ff450cdbdee0b8cb6b9d653d6d2fa892de29be31 commit ff450cdbdee0b8cb6b9d653d6d2fa892de29be31 Author: Arjun Shankar <arjun@redhat.com> Date: Tue May 24 17:57:36 2022 +0200 Fix deadlock when pthread_atfork handler calls pthread_atfork or dlclose In multi-threaded programs, registering via pthread_atfork, de-registering implicitly via dlclose, or running pthread_atfork handlers during fork was protected by an internal lock. This meant that a pthread_atfork handler attempting to register another handler or dlclose a dynamically loaded library would lead to a deadlock. This commit fixes the deadlock in the following way: During the execution of handlers at fork time, the atfork lock is released prior to the execution of each handler and taken again upon its return. Any handler registrations or de-registrations that occurred during the execution of the handler are accounted for before proceeding with further handler execution. If a handler that hasn't been executed yet gets de-registered by another handler during fork, it will not be executed. If a handler gets registered by another handler during fork, it will not be executed during that particular fork. The possibility that handlers may now be registered or deregistered during handler execution means that identifying the next handler to be run after a given handler may register/de-register others requires some bookkeeping. The fork_handler struct has an additional field, 'id', which is assigned sequentially during registration. Thus, handlers are executed in ascending order of 'id' during 'prepare', and descending order of 'id' during parent/child handler execution after the fork. Two tests are included: * tst-atfork3: Adhemerval Zanella <adhemerval.zanella@linaro.org> This test exercises calling dlclose from prepare, parent, and child handlers. * tst-atfork4: This test exercises calling pthread_atfork and dlclose from the prepare handler. [BZ #24595, BZ #27054] Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 52a103e237329b9f88a28513fe7506ffc3bd8ced)
This should now be fixed via the above mentioned commits in master (2.36), and backported to the 2.35 and 2.34 release branches.