manual, NEWS: Document malloc side effect of dynamic TLS changes
Checks
Context |
Check |
Description |
redhat-pt-bot/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 |
success
|
Testing passed
|
redhat-pt-bot/TryBot-32bit |
success
|
Build for i686
|
linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_glibc_build--master-arm |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_glibc_check--master-arm |
success
|
Testing passed
|
Commit Message
The increased malloc subsystem usage is a side effect of
commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls
access after dlopen [BZ #19924]").
---
NEWS | 5 +++++
manual/memory.texi | 8 ++++++++
2 files changed, 13 insertions(+)
Comments
Florian Weimer <fweimer@redhat.com> writes:
> +@code{malloc} internal. For example, the @code{fopen}, @code{opendir},
s/internal/internally/
* DJ Delorie:
> Florian Weimer <fweimer@redhat.com> writes:
>> +@code{malloc} internal. For example, the @code{fopen}, @code{opendir},
>
> s/internal/internally/
Thanks, sent a v2.
Florian
The 01/15/2024 16:19, Florian Weimer wrote:
> The increased malloc subsystem usage is a side effect of
> commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls
> access after dlopen [BZ #19924]").
thanks.
looks good with some comments
>
> ---
> NEWS | 5 +++++
> manual/memory.texi | 8 ++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/NEWS b/NEWS
> index 1da3a6e6ee..a87271e573 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -80,6 +80,11 @@ Deprecated and removed features, and other changes affecting compatibility:
> of GNU libc are advised to check whether their build processes can be
> simplified.
>
> +* The dynamic linker calls the malloc and free functions in more cases
i would expand this to ".. calls the malloc and free functions in more
cases during tls access if .." (not very important but makes it clearer
what's going on)
> + if a shared object with dynamic TLS is loaded and unloaded. This can
> + result in an infinite recursion if a malloc replacement libraries or
singular 'library'
> + its dependencies uses dynamic TLS instead of initial-exec TLS.
> +
> * The ia64*-*-linux-gnu configurations are no longer supported.
>
> Changes to build and runtime requirements:
> diff --git a/manual/memory.texi b/manual/memory.texi
> index 258fdbd3a0..4193b45e98 100644
> --- a/manual/memory.texi
> +++ b/manual/memory.texi
> @@ -1815,6 +1815,14 @@ using shared object dependencies or @code{LD_PRELOAD}. For static
> linking, the @code{malloc} replacement library must be linked in before
> linking against @code{libc.a} (explicitly or implicitly).
>
> +Care must be taken not to use functionality from @theglibc{} that uses
> +@code{malloc} internal. For example, the @code{fopen}, @code{opendir},
internally
> +@code{dlopen}, and @code{pthread_setspecific} functions currently use
> +the @code{malloc} subsystem internally. If the replacement
> +@code{malloc} or its dependencies use thread-local storage (TLS), it
> +must use the initial-exec TLS model, and not one of the dynamic TLS
> +variants.
OK.
> +
> @strong{Note:} Failure to provide a complete set of replacement
> functions (that is, all the functions used by the application,
> @theglibc{}, and other linked-in libraries) can lead to static linking
>
@@ -80,6 +80,11 @@ Deprecated and removed features, and other changes affecting compatibility:
of GNU libc are advised to check whether their build processes can be
simplified.
+* The dynamic linker calls the malloc and free functions in more cases
+ if a shared object with dynamic TLS is loaded and unloaded. This can
+ result in an infinite recursion if a malloc replacement libraries or
+ its dependencies uses dynamic TLS instead of initial-exec TLS.
+
* The ia64*-*-linux-gnu configurations are no longer supported.
Changes to build and runtime requirements:
@@ -1815,6 +1815,14 @@ using shared object dependencies or @code{LD_PRELOAD}. For static
linking, the @code{malloc} replacement library must be linked in before
linking against @code{libc.a} (explicitly or implicitly).
+Care must be taken not to use functionality from @theglibc{} that uses
+@code{malloc} internal. For example, the @code{fopen}, @code{opendir},
+@code{dlopen}, and @code{pthread_setspecific} functions currently use
+the @code{malloc} subsystem internally. If the replacement
+@code{malloc} or its dependencies use thread-local storage (TLS), it
+must use the initial-exec TLS model, and not one of the dynamic TLS
+variants.
+
@strong{Note:} Failure to provide a complete set of replacement
functions (that is, all the functions used by the application,
@theglibc{}, and other linked-in libraries) can lead to static linking