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: 2.25 freeze status


On 01/02/17 07:37, Alexandre Oliva wrote:
> On Jan 27, 2017, Florian Weimer <fweimer@redhat.com> wrote:
> 
>>> writing to the dtv of other threads is neither
>>> necessary nor correct.
> 
>> Let's do it then.  Is this patch okay?
> 
> I see you're taken out the reversal of
> 
> 	* elf/dl-reloc.c (_dl_nothread_init_static_tls)
> 
> from the patch I proposed back on Sept 24 for BZ #19826.
> 
> I don't think it is right to drop that part.
> 
> That's the nptl-less TLS initializer analogous to
> 
> 	* nptl/allocatestack.c (init_one_static_tls)
> 
> in programs that link with libpthread.

but it does not touch the dtv of other threads.
so it does not seem harmful only inconsistent.

> Before the fix for BZs #17090, #17620, #17621 and #17628 (f8aeae3473),
> we'd just abort if the static TLS modid grew past the initial DTV size.
> I'm not sure there's code in place to resize the DTV within dlopen
> before calling GL(dl_init_static_tls), that resolves to either
> _dl_nothread_init_static_tls, that deals with the single thread, or
> __pthread_init_static_tls, that calls init_one_static_tls for each
> thread, so dlopening multiple static-TLS libs in a program not linked
> with libpthread might abort at the assert that checks that the modid is
> lower than the DTV length.

_dl_update_slotinfo_list is called there which
does _dl_resize_dtv so it's fine.
https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-open.c;h=cec54db413cc47e5840ebf94d2d9881bf1f7bf34#l547

(_dl_resize_dtv aborts in case of allocation
failure, so dlopen should do this differently,
but oom crash is a separate long standing issue)

> Unless you've verified that this is safe, I'd strongly advise against
> dropping the analogous change for single-threaded programs from the
> patch I had proposed.

reverting both hunks is also fine with me if
you consider that safer. i thought it would
be easier to get a quick consensus if we only
involve the problematic hunk.

> I'd also suggest adding comments to the effect that 'we leave it for
> tls_get_addr to update each thread's DTV, since it might need resizing'.
> 
> Thanks for taking care of this,
> 


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