This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2 07/12] elf: Move vDSO setup to rtld (BZ#24967)



On 13/12/2019 10:56, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>> This IFUNC resolver is still not valid because _rtld_global_ro has a
>>> relocation dependency.
>>
>> Afaik with current ld guaranties, .rel{a}.dyn will be sort prior ifunc
>> so _rtld_global_ro should be reallocated prior the ifunc itself.
> 
> But that's intra-DSO.  It does not necessarily affect cross-DSO
> relocation ordering.  In theory, the DT_NEEDED ordering should make this
> work, except for the static dlopen case, where you get a
> default-initialized _rtld_global_ro from the inactive (inner) loader.
> The latter is why some architectures use _dl_var_init for essential
> non-loader data, and why getauxval is currently broken for something
> that is dlopen'ed from a statically linked program (bug 20802).

Another point to just moved out from ifunc to implement such functions,
although imho this specific usercase should not prevent this change,
since by fixing this issue in also fix the ifunc selection.

> 
>>> What we should do instead is to patch the vDSO function pointers (and
>>> pretty much all shared variables, including the page size) into
>>> libc.so.6 right after loading it (before relocation).  I had hoped to
>>> post a patch for this, but the prerequisite
>>>
>>>   <https://sourceware.org/ml/libc-alpha/2019-11/msg00977.html>
>>>
>>> has not been reviewed.  It provides _dl_lookup_direct, which we could
>>> use to get access to this global variables structure very efficiently.
>>
>> We can go on this way (which is a rather complex solution with might add
>> even more pitfalls). However another much simple possibility is to make 
>> gettimeoday and time use normal function that calls the vDSO directly.  
>> On x86_64 haswell (i7-4790K) I see just 7% increase of latency to by 
>> using INLINE_VSYSCALL with my patch, which I think it quite acceptable. 
> 
> It's not more complex overall because we already need _dl_var_init on
> some architectures.  This new mechanism would replace that and do away
> with undo-RELRO/_dl_var_init/reapply-RELRO sequence.

It is more complex to maintain a specific initialization code for some
arch and it is orthogonal to fix static dlopen. It also requires more 
patch review iterations to get some more piece in place to keep providing
the ifunc optimization. 

So I see that if you think that the specific ifunc scenario, which is 
already broken, is a block for BZ#24967 I see it is better to remove the
ifunc optimization and reinstate it once this ifunc scenario is fixed.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]