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

[Florian Weimer]

* 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.

I agree, documenting this would be helpful.

>> +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.

Correct, I've added a null check.  The (eventual) callers already check
for allocation failure.

Thanks,
Florian