manual, NEWS: Document malloc side effect of dynamic TLS changes

The increased malloc subsystem usage is a side effect of
commit d2123d6827 ("elf: Fix slow tls
access after dlopen [BZ #19924]").

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

NEWS

@@ -91,6 +91,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:

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