Under bug 1991001, we are considering backporting changes to the DTV TLS management, so that it aligns with upstream. This is a prerequisite for backporting an eventual upstream fix for this bug here, which does not exist at this time.

We backported the glibc.rtld.optional_static_tls upstream tunable as part of bug 1817513. With the tunable, it is possible to get initial-exec TLS in dlopen'ed shared objects working in more cases. Initial-exec TLS does not suffer from the performance degradation, so it might be an alternative approach. For instance, glibc malloc uses initial-exec TLS to access its thread-local data, so it is not affected by this.

Upstream commit:

commit d2123d68275acc0f061e73d5f86ca504e0d5a344
Author: Szabolcs Nagy <szabolcs.nagy>
Date:   Tue Feb 16 12:55:13 2021 +0000

    elf: Fix slow tls access after dlopen [BZ #19924]
    
    In short: __tls_get_addr checks the global generation counter and if
    the current dtv is older then _dl_update_slotinfo updates dtv up to the
    generation of the accessed module. So if the global generation is newer
    than generation of the module then __tls_get_addr keeps hitting the
    slow dtv update path. The dtv update path includes a number of checks
    to see if any update is needed and this already causes measurable tls
    access slow down after dlopen.
    
    It may be possible to detect up-to-date dtv faster.  But if there are
    many modules loaded (> TLS_SLOTINFO_SURPLUS) then this requires at
    least walking the slotinfo list.
    
    This patch tries to update the dtv to the global generation instead, so
    after a dlopen the tls access slow path is only hit once.  The modules
    with larger generation than the accessed one were not necessarily
    synchronized before, so additional synchronization is needed.
    
    This patch uses acquire/release synchronization when accessing the
    generation counter.
    
    Note: in the x86_64 version of dl-tls.c the generation is only loaded
    once, since relaxed mo is not faster than acquire mo load.
    
    I have not benchmarked this. Tested by Adhemerval Zanella on aarch64,
    powerpc, sparc, x86 who reported that it fixes the performance issue
    of bug 19924.
    
    Reviewed-by: Adhemerval Zanella  <adhemerval.zanella>

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues.