[PATCH v3 31/32] elf: Add hash tables to speed up DT_NEEDED, dlopen lookups

[Joseph Myers]

On Thu, 7 Dec 2023, Florian Weimer wrote:

> The alloca copy in _dl_load_cache_lookup is no longer needed
> because _dl_libname_allocate does not use the interposable malloc,
> and so cannot call back into the dynamic linker.

The following is something I don't expect to be addressed in this patch 
series, but it seems relevant to issues I needed to consider in review (of 
what might happen at particular times in the dynamic linker):

There are various ways in which the dynamic linker may call user code, 
such as interposed malloc, IFUNC resolvers, audit modules, preinit / init 
/ fini functions.  It's not very clear to me (a) when we consider it valid 
for such user code to itself do things that might affect dynamic linker 
state, such as calling dlopen or dlclose or creating or terminating or 
joining threads or using longjmp to jump back into user code outside the 
dynamic linker, or (b) the extent to which we have test coverage of 
whatever such cases we consider valid.  It would be helpful to have 
documentation (for users, not just internal) of any restrictions there 
might be on what can be done in user code called in such contexts from the 
dynamic linker, and to make sure we have tests with thorough coverage of 
all such cases that we consider valid but could still readily be a source 
of bugs.

> +struct libname *
> +_dl_libname_allocate_hash (const char *name, uint32_t hash)
> +{
> +  size_t name_len = strlen (name) + 1;
> +  struct libname *result
> +    = _dl_protmem_allocate (offsetof (struct libname, name) + name_len);
> +  result->map = NULL;

I'd expect this to check for a NULL return from _dl_protmem_allocate and 
indicate error itself (by returning NULL?) accordingly.

-- 
Joseph S. Myers
josmyers@redhat.com