Message ID | 87o7dm62vu.fsf@oldenburg.str.redhat.com |
---|---|
State | New |
Headers | show |
Series | manual, NEWS: Document malloc side effect of dynamic TLS changes | expand |
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 >
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 + 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: 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}, +@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