This is the mail archive of the glibc-cvs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[glibc/fw/bug25112] (2 commits) Avoid late dlopen failure due to scope, TLS slotinfo update


The branch 'fw/bug25112' was updated to point to:

 93e07b2... Avoid late dlopen failure due to scope, TLS slotinfo update

It previously pointed to:

 9c623ce... WIP fix other rollback issues related to malloc

Diff:

!!! WARNING: THE FOLLOWING COMMITS ARE NO LONGER ACCESSIBLE (LOST):
-------------------------------------------------------------------

  9c623ce... WIP fix other rollback issues related to malloc
  f404f78... Avoid late malloc failure in dlopen [BZ #25112]

commit 9c623ce625ede3ebd5fad9568512ecc3edcd1549
Author: Florian Weimer <fweimer@redhat.com>
Date:   Thu Oct 24 13:44:18 2019 +0200

    WIP fix other rollback issues related to malloc

commit f404f789ce2a968281ddadbe5df9458a0517d623
Author: Florian Weimer <fweimer@redhat.com>
Date:   Thu Oct 17 19:58:57 2019 +0200

    Avoid late malloc failure in dlopen [BZ #25112]
    
    The call to add_to_global in dl_open_worker happens after running ELF
    constructors for new objects.  At this point, proper recovery from
    malloc failure would be quite complicated: We would have to run the
    ELF destructors and close all opened objects, something that we
    currently do not do.
    
    Instead, this change splits add_to_global into two phases,
    add_to_global_prepare (which can raise an exception, called before ELF
    constructors run), and add_to_global_finish (which cannot, called
    after ELF constructors).  A complication arises due to recursive
    dlopen: After the inner dlopen consumes some space, the pre-allocation
    in the outer dlopen may no longer be sufficient.  A new member in the
    namespace structure, _ns_global_scope_pending_adds keeps track of the
    maximum number of objects that need to be added to the global scope.
    This enables the inner add_to_global_prepare call to take into account
    the needs of an outer dlopen.
    
    Most code in the dynamic linker assumes that the number of global
    scope entries fits into an unsigned int (matching the r_nlist member
    of struct r_scop_elem).  Therefore, change the type of
    _ns_global_scope_alloc to unsigned int (from size_t), and add overflow
    checks.
    
    Tested on x86_64-linux-gnu and i686-linux-gnu.


Summary of changes (added commits):
-----------------------------------

  93e07b2... Avoid late dlopen failure due to scope, TLS slotinfo update
  f0ead7b... Avoid late failure in dlopen in global scope update [BZ #25

commit 93e07b2f9ef6825c7165f4587d2204464c83959a
Author: Florian Weimer <fw@deneb.enyo.de>
Date:   Mon Oct 28 13:15:19 2019 +0100

    Avoid late dlopen failure due to scope, TLS slotinfo updates [BZ #25112]
    
    This change splits the scope and TLS slotinfo updates in dlopen into
    two parts: one to resize the data structures, and one to actually apply
    the update.  The call to add_to_global_prepare in dl_open_worker is moved
    before the demarcation point at which no further memory allocations are
    allowed.
    
    _dl_add_to_slotinfo is adjusted to make the list update optional.  There
    is some optimization possibility here because we could grow the slotinfo
    list of arrays in a single call, one the largest TLS modid is known.
    
    This commit does not fix the fatal meory allocation failure in
    _dl_update_slotinfo.  Ideally, this error during dlopen should be
    recoverable.
    
    The update order of scopes and TLS data structures is retained, although
    it appears to be more correct to fully initialize TLS first, and then
    expose symbols in the newly loaded objects via the scope update.
    
    Tested on x86_64-linux-gnu.

commit f0ead7b63b95ef1920197f50b6d4abf407f9ebe7
Author: Florian Weimer <fweimer@redhat.com>
Date:   Thu Oct 17 19:58:57 2019 +0200

    Avoid late failure in dlopen in global scope update [BZ #25112]
    
    The call to add_to_global in dl_open_worker happens after running ELF
    constructors for new objects.  At this point, proper recovery from
    malloc failure would be quite complicated: We would have to run the
    ELF destructors and close all opened objects, something that we
    currently do not do.
    
    Instead, this change splits add_to_global into two phases,
    add_to_global_prepare (which can raise an exception, called before ELF
    constructors run), and add_to_global_finish (which cannot, called
    after ELF constructors).  A complication arises due to recursive
    dlopen: After the inner dlopen consumes some space, the pre-allocation
    in the outer dlopen may no longer be sufficient.  A new member in the
    namespace structure, _ns_global_scope_pending_adds keeps track of the
    maximum number of objects that need to be added to the global scope.
    This enables the inner add_to_global_prepare call to take into account
    the needs of an outer dlopen.
    
    Most code in the dynamic linker assumes that the number of global
    scope entries fits into an unsigned int (matching the r_nlist member
    of struct r_scop_elem).  Therefore, change the type of
    _ns_global_scope_alloc to unsigned int (from size_t), and add overflow
    checks.
    
    Tested on x86_64-linux-gnu and i686-linux-gnu.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]