* [Bug libc/27054] pthread_atfork handlers that call pthread_atfork deadlock
2020-12-11 15:26 [Bug libc/27054] New: pthread_atfork handlers that call pthread_atfork deadlock fweimer at redhat dot com
@ 2020-12-11 15:31 ` fweimer at redhat dot com
2020-12-15 16:37 ` adhemerval.zanella at linaro dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: fweimer at redhat dot com @ 2020-12-11 15:31 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=27054
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugzilla.redhat.com
| |/show_bug.cgi?id=1888660
CC| |fweimer at redhat dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/27054] pthread_atfork handlers that call pthread_atfork deadlock
2020-12-11 15:26 [Bug libc/27054] New: pthread_atfork handlers that call pthread_atfork deadlock fweimer at redhat dot com
2020-12-11 15:31 ` [Bug libc/27054] " fweimer at redhat dot com
@ 2020-12-15 16:37 ` adhemerval.zanella at linaro dot org
2020-12-15 16:46 ` fweimer at redhat dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2020-12-15 16:37 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=27054
Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |adhemerval.zanella at linaro dot o
| |rg
--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Would it be a duplicate of BZ#24595?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/27054] pthread_atfork handlers that call pthread_atfork deadlock
2020-12-11 15:26 [Bug libc/27054] New: pthread_atfork handlers that call pthread_atfork deadlock fweimer at redhat dot com
2020-12-11 15:31 ` [Bug libc/27054] " fweimer at redhat dot com
2020-12-15 16:37 ` adhemerval.zanella at linaro dot org
@ 2020-12-15 16:46 ` fweimer at redhat dot com
2022-05-25 9:31 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: fweimer at redhat dot com @ 2020-12-15 16:46 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=27054
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://sourceware.org/bugz
| |illa/show_bug.cgi?id=24595
--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
Definitely related, but that really depends on how the bugs are fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/27054] pthread_atfork handlers that call pthread_atfork deadlock
2020-12-11 15:26 [Bug libc/27054] New: pthread_atfork handlers that call pthread_atfork deadlock fweimer at redhat dot com
` (2 preceding siblings ...)
2020-12-15 16:46 ` fweimer at redhat dot com
@ 2022-05-25 9:31 ` cvs-commit at gcc dot gnu.org
2022-05-30 11:39 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-25 9:31 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=27054
--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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>
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/27054] pthread_atfork handlers that call pthread_atfork deadlock
2020-12-11 15:26 [Bug libc/27054] New: pthread_atfork handlers that call pthread_atfork deadlock fweimer at redhat dot com
` (3 preceding siblings ...)
2022-05-25 9:31 ` cvs-commit at gcc dot gnu.org
@ 2022-05-30 11:39 ` cvs-commit at gcc dot gnu.org
2022-05-30 15:45 ` cvs-commit at gcc dot gnu.org
2022-05-31 16:24 ` arjun.is at lostca dot se
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-30 11:39 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=27054
--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.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)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/27054] pthread_atfork handlers that call pthread_atfork deadlock
2020-12-11 15:26 [Bug libc/27054] New: pthread_atfork handlers that call pthread_atfork deadlock fweimer at redhat dot com
` (4 preceding siblings ...)
2022-05-30 11:39 ` cvs-commit at gcc dot gnu.org
@ 2022-05-30 15:45 ` cvs-commit at gcc dot gnu.org
2022-05-31 16:24 ` arjun.is at lostca dot se
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-30 15:45 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=27054
--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/27054] pthread_atfork handlers that call pthread_atfork deadlock
2020-12-11 15:26 [Bug libc/27054] New: pthread_atfork handlers that call pthread_atfork deadlock fweimer at redhat dot com
` (5 preceding siblings ...)
2022-05-30 15:45 ` cvs-commit at gcc dot gnu.org
@ 2022-05-31 16:24 ` arjun.is at lostca dot se
6 siblings, 0 replies; 8+ messages in thread
From: arjun.is at lostca dot se @ 2022-05-31 16:24 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=27054
Arjun Shankar <arjun.is at lostca dot se> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Assignee|unassigned at sourceware dot org |arjun.is at lostca dot se
CC| |arjun.is at lostca dot se
Target Milestone|--- |2.36
Status|NEW |RESOLVED
--- Comment #6 from Arjun Shankar <arjun.is at lostca dot se> ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread