Re: Why does elf/dl-load.c have local_strdup?

["Carlos O'Donell" <carlos at redhat dot com>]

On 10/20/2014 04:41 PM, Roland McGrath wrote:
> I don't see any reason for it.  When it was added, it was replacing
> open-coded malloc+memcpy sequences.  But I don't know why the normal
> implementation could not have been used.  Name space issues might mean we
> should only use __strdup here, but that could have been done at the time
> local_strdup was added too.

Thanks, I had not considered namespace issues.

I'm fixing this partly because I've just found that ld.so.cache management
has no ref counting on the mmap, and recursive dlopen leads to segfaults if
you have a malloc hook that calls dlopen. The deepest dlopen, as it completes,
unmaps the cache, and the next deepest dlopen segfaults trying to reference
data in the cache it expects to be valid.

I figure that malloc hooks should be allowed to call dlopen, and we should
either ref-count ld.so.cache mmap, or better yet, just change the contract
of _dl_load_cache_lookup to return a copy of the caches string.

In 99% of the caches the hot path is that the cache has the file, and
you're going to strdup anyway, so why not just do it while you know the
cache to be valid and avoid this entire issue? Well, one issue is that any
strdup in _dl_load_cache_lookup will trigger the problem (call malloc,
which calls a malloc hook, which calls dlopen, which later unmaps the
cache you're trying to copy). So you'd need an intermediate alloca,
followed by a strdup.

Is `alloca + strdup` worse or better than `ref-counted ld.so.cache mapping?`

Cheers,
Carlos.