Back to bug 1871396
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Red Hat Bugzilla | 2020-08-23 02:49:33 UTC | Pool ID | sst_platform_tools_rhel_8 | |
| Sergey Kolosov | 2020-09-17 07:30:21 UTC | CC | skolosov | |
| Florian Weimer | 2020-10-05 08:11:41 UTC | CC | sipoyare | |
| Tulio Magno Quites Machado Filho | 2021-01-19 14:53:47 UTC | CC | tulioqm | |
| Red Hat One Jira (issues.redhat.com) | 2021-01-19 14:55:12 UTC | Link ID | Red Hat Issue Tracker - Private RHELPLAN-51914 | |
| Florian Weimer | 2021-01-19 15:03:47 UTC | Flags | needinfo?(tulioqm) | |
| Tulio Magno Quites Machado Filho | 2021-01-19 15:20:56 UTC | Flags | needinfo?(tulioqm) | |
| Hanns-Joachim Uhl | 2021-01-20 09:01:24 UTC | Target Release | 8.0 | 8.4 |
| CC | bugproxy, hannsj_uhl | |||
| Link ID | IBM Linux Technology Center 190906 | |||
| Blocks | 1796871 | |||
| Matt Newsome | 2021-02-01 15:00:18 UTC | Keywords | Triaged | |
| Florian Weimer | 2021-02-02 15:46:59 UTC | Status | NEW | MODIFIED |
| Fixed In Version | glibc-2.28-145.el8 | |||
| Assignee | glibc-bugzilla | fweimer | ||
| Sergey Kolosov | 2021-02-02 15:57:04 UTC | QA Contact | qe-baseos-tools-bugs | skolosov |
| Florian Weimer | 2021-02-02 16:14:07 UTC | Doc Text | Cause: The glibc dynamic linker uses available static thread-local storage (TLS) space for dynamic TLS, with no way to override this optimization. Consequence: Loading additional shared objects at run time using dlopen can fail because no static TLS space is available, particularly on the aarch64 and ppc64le architectures. Fix: The dynamic linker restricts part of the static TLS area to static TLS allocations and does not use them for dynamic TLS optimizations. Result: dlopen calls succeed in more cases by default. A new tunable, glibc.rtld.optional_static_tls, can be used for applications whose TLS allocation requirements are not met by the default heuristics. | |
| Doc Type | If docs needed, set a value | Bug Fix | ||
| Divya | 2021-02-03 06:08:01 UTC | CC | dikonoor | |
| Hanns-Joachim Uhl | 2021-02-03 12:17:49 UTC | CC | dhorak, jomiller | |
| Hanns-Joachim Uhl | 2021-02-03 13:56:43 UTC | Flags | needinfo?(bugproxy) | |
| Severity | medium | urgent | ||
| errata-xmlrpc | 2021-02-10 20:00:57 UTC | Status | MODIFIED | ON_QA |
| Sergey Kolosov | 2021-02-18 14:58:51 UTC | Status | ON_QA | VERIFIED |
| IBM Bug Proxy | 2021-02-25 14:01:58 UTC | Flags | needinfo?(bugproxy) | |
| Petr Kovar | 2021-03-01 15:15:02 UTC | Docs Contact | zzoubkov | |
| Florian Weimer | 2021-03-08 12:27:00 UTC | Flags | needinfo?(dikonoor) | |
| Divya | 2021-03-11 04:29:02 UTC | Flags | needinfo?(dikonoor) | |
| SravanK | 2021-03-15 09:16:50 UTC | CC | myselfsravank | |
| Florian Weimer | 2021-03-15 09:57:43 UTC | Attachment #1763343 Attachment description | new zip file | LD_DEBUG output |
| Florian Weimer | 2021-03-15 09:57:49 UTC | Attachment #1763336 Attachment is obsolete | 0 | 1 |
| Zuzana Zoubkova | 2021-03-15 16:10:26 UTC | Doc Text | Cause: The glibc dynamic linker uses available static thread-local storage (TLS) space for dynamic TLS, with no way to override this optimization. Consequence: Loading additional shared objects at run time using dlopen can fail because no static TLS space is available, particularly on the aarch64 and ppc64le architectures. Fix: The dynamic linker restricts part of the static TLS area to static TLS allocations and does not use them for dynamic TLS optimizations. Result: dlopen calls succeed in more cases by default. A new tunable, glibc.rtld.optional_static_tls, can be used for applications whose TLS allocation requirements are not met by the default heuristics. | .The `glibc` dynamic linker now restricts a part of the static thread-local storage space to static TLS allocations Previously, the `glibc` dynamic linker used all available static thread-local storage (TLS) space for dynamic TLS, on a first come, first served basis. Consequently, loading additional shared objects at run time using the `dlopen` function sometimes failed, because dynamic TLS allocations had already consumed all available static TLS space. This problem occurred particularly on the 64-bit ARM architecture and IBM Power Systems. Now, the dynamic linker restricts a part of the static TLS area to static TLS allocations, and does not use this space for dynamic TLS optimizations. As a result, `dlopen` calls succeed in more cases by default. Applications that require more allocated static TLS than the default setting allows can use a new tunable `glibc.rtld.optional_static_tls`. |
| Flags | needinfo?(fweimer) | |||
| Florian Weimer | 2021-03-15 16:14:09 UTC | Flags | needinfo?(fweimer) | |
| Zuzana Zoubkova | 2021-03-22 09:38:23 UTC | Doc Text | .The `glibc` dynamic linker now restricts a part of the static thread-local storage space to static TLS allocations Previously, the `glibc` dynamic linker used all available static thread-local storage (TLS) space for dynamic TLS, on a first come, first served basis. Consequently, loading additional shared objects at run time using the `dlopen` function sometimes failed, because dynamic TLS allocations had already consumed all available static TLS space. This problem occurred particularly on the 64-bit ARM architecture and IBM Power Systems. Now, the dynamic linker restricts a part of the static TLS area to static TLS allocations, and does not use this space for dynamic TLS optimizations. As a result, `dlopen` calls succeed in more cases by default. Applications that require more allocated static TLS than the default setting allows can use a new tunable `glibc.rtld.optional_static_tls`. | .The `glibc` dynamic linker now restricts a part of the static thread-local storage space to static TLS allocations Previously, the `glibc` dynamic linker used all available static thread-local storage (TLS) space for dynamic TLS, on a first come, first served basis. Consequently, loading additional shared objects at run time using the `dlopen` function sometimes failed, because dynamic TLS allocations had already consumed all available static TLS space. This problem occurred particularly on the 64-bit ARM architecture and IBM Power Systems. Now, the dynamic linker restricts part of the static TLS area to static TLS allocations and does not use this space for dynamic TLS optimizations. As a result, `dlopen` calls succeed in more cases with the default setting. Applications that require more allocated static TLS than the default setting allows can use a new `glibc.rtld.optional_static_tls` tunable. |
| Zuzana Zoubkova | 2021-03-22 10:18:42 UTC | Doc Text | .The `glibc` dynamic linker now restricts a part of the static thread-local storage space to static TLS allocations Previously, the `glibc` dynamic linker used all available static thread-local storage (TLS) space for dynamic TLS, on a first come, first served basis. Consequently, loading additional shared objects at run time using the `dlopen` function sometimes failed, because dynamic TLS allocations had already consumed all available static TLS space. This problem occurred particularly on the 64-bit ARM architecture and IBM Power Systems. Now, the dynamic linker restricts part of the static TLS area to static TLS allocations and does not use this space for dynamic TLS optimizations. As a result, `dlopen` calls succeed in more cases with the default setting. Applications that require more allocated static TLS than the default setting allows can use a new `glibc.rtld.optional_static_tls` tunable. | .The `glibc` dynamic linker now restricts part of the static thread-local storage space to static TLS allocations Previously, the `glibc` dynamic linker used all available static thread-local storage (TLS) space for dynamic TLS, on a first come, first served basis. Consequently, loading additional shared objects at run time using the `dlopen` function sometimes failed, because dynamic TLS allocations had already consumed all available static TLS space. This problem occurred particularly on the 64-bit ARM architecture and IBM Power Systems. Now, the dynamic linker restricts part of the static TLS area to static TLS allocations and does not use this space for dynamic TLS optimizations. As a result, `dlopen` calls succeed in more cases with the default setting. Applications that require more allocated static TLS than the default setting allows can use a new `glibc.rtld.optional_static_tls` tunable. |
| errata-xmlrpc | 2021-05-18 00:31:04 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2021-05-18 14:36:39 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2021-05-18 14:36:39 UTC | |||
| Pavel Najman | 2021-09-17 12:24:26 UTC | Pool ID | sst_platform_tools_rhel_8 | sst_pt_pcp_rhel_8 |
| Pavel Najman | 2021-09-17 12:34:06 UTC | Pool ID | sst_pt_pcp_rhel_8 | sst_pt_gcc_glibc_rhel_8 |
| Mark O'Brien | 2023-07-18 14:30:35 UTC | Pool ID | sst_pt_glibc_rhel_8 | sst_pt_libraries_rhel_8 |
Back to bug 1871396