[Bug nptl/24595] [2.28 Regression]: Deadlock in atfork handler which calls dlclose

[Bug nptl/24595] [2.28 Regression]: Deadlock in atfork handler which calls dlclose

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24595

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=27054

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/24595] [2.28 Regression]: Deadlock in atfork handler which calls dlclose

[arjun.is at lostca dot se]

https://sourceware.org/bugzilla/show_bug.cgi?id=24595

Arjun Shankar <arjun.is at lostca dot se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassigned at sourceware dot org   |arjun.is at lostca dot se
   Target Milestone|---                         |2.36
                 CC|                            |arjun.is at lostca dot se

--- Comment #9 from Arjun Shankar <arjun.is at lostca dot se> ---
This should now be fixed in master with:

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.

[Bug nptl/24595] [2.28 Regression]: Deadlock in atfork handler which calls dlclose

[arjun.is at lostca dot se]

https://sourceware.org/bugzilla/show_bug.cgi?id=24595

--- Comment #10 from Arjun Shankar <arjun.is at lostca dot se> ---
I have also backported the fix to release/2.35/master and release/2.34/master.

-- 
You are receiving this mail because:
You are on the CC list for the bug.