Re: A possible libc/dlmopen/pthreads bug

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 24/01/2018 17:34, Szabolcs Nagy wrote:
> On 24/01/18 17:25, Adhemerval Zanella wrote:
>> In fact I think Vivek examples of running process with two different libcs
>> are working mainly because the different glibc define and access the shared
>> resources in same manner.  I bet it will break the moment we change some
>> state internal layout or semantic (for instance the __stack_user struct size).
> 
> even if the two libc has same code and same layout for
> internal data structures it is completely broken:
> there are two copies of the libc global data section
> with inconsistent content.
> 
> if printf called twice via different libcs they get
> buffered independently, but write to the same fd, so
> the observable effect on stdout can be out of order,
> fflush on namespace boundary does not help since the
> locks of one libc don't work on the other, the writes
> can happen concurrently.
> 
> setxid has to coordinate with all threads via signals,
> even with the ones created by the other libc.
> 
> same for atfork handlers: the handlers of the other
> libc has to run too.
> 
> same of tls/tsd dtors: at thread exit the other libc
> tls/tsd data should be freed too.
> 
> the dynamic loader + libc + libpthread needs to have
> one unique instance or some apis won't work across
> all instances.
> 

Thanks for bring this up, it seems that Vivek usercases only cover a
narrow possible ones.  Even more I think we should really limit
dlmopen scope for glibc own dso instances.