Message ID | 87zfwxmlln.fsf@oldenburg.str.redhat.com |
---|---|
State | New |
Headers | show |
Series | [v3] manual, NEWS: Document malloc side effect of dynamic TLS changes | expand |
The 01/22/2024 16:30, Florian Weimer wrote: > The increased malloc subsystem usage is a side effect of > commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls > access after dlopen [BZ #19924]"). looks good. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com> > > --- > v3: Wording changes suggested by Szabolcs. > > NEWS | 6 ++++++ > manual/memory.texi | 8 ++++++++ > 2 files changed, 14 insertions(+) > > diff --git a/NEWS b/NEWS > index 1da3a6e6ee..6fff3fe6fa 100644 > --- a/NEWS > +++ b/NEWS > @@ -80,6 +80,12 @@ 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 > + during TLS access if a shared object with dynamic TLS is loaded and > + unloaded. This can result in an infinite recursion if a malloc > + replacement library or its dependencies use 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..fb875f4c3c 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} internally. 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 > > base-commit: 49b668324d12fde8ed42ceecee28f11b4e49b9b0 >
diff --git a/NEWS b/NEWS index 1da3a6e6ee..6fff3fe6fa 100644 --- a/NEWS +++ b/NEWS @@ -80,6 +80,12 @@ 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 + during TLS access if a shared object with dynamic TLS is loaded and + unloaded. This can result in an infinite recursion if a malloc + replacement library or its dependencies use 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..fb875f4c3c 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} internally. 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