[Bug libc/21793] glibc does not update the pid/tid cache after clone()

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21793

--- Comment #6 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Florian Weimer from comment #5)
> (In reply to Adhemerval Zanella from comment #4)
> 
> > Should we considere this NOTABUG/WONTFIX or add back tid update on clone?
> > Chrome developers seemed to not agree with us that glibc function are not
> > reliable after a clone call
> 
> They *should* be reliable after a clone call if the call creates a new
> process.

Should it? We have 'fork' exactly for this case which setup us all the required
internal field for correct glibc usage. I give you that with current clone
flags this is a limited API.

> 
> >  since they are now updating the tid cache by
> > themselves [1] (still a fragile fix imho).
> 
> > [1]
> > https://chromium.googlesource.com/chromium/src.git/+/
> > 24df419517bb8ca8ac2b75eb752bd9a133267108%5E%21/#F1
> 
> That's clearly a bogus change and will break once we change the TCB layout.
>  
> > I still would prefer to document clone and glibc interaction limitation
> > rather than provide incomplete and possible problematic solutions.
> 
> Right, that seems worthwhile.  We could perhaps push the responsibility to
> request a TID cache update to the caller, rather than trying to parse the
> flags argument.  That is, provide a different interface for a vfork-style
> clone which would not update the cache (because it is shared with the
> parent).

I am not very found of providing a limited clone interface mainly because
interaction with glibc internals could have subtle bugs. Some I can think of:

1. It will need to pass CLONE_CHILD_SETTID and CLONE_CHILD_CLEARTID along with
TCB tid field. What happens if caller uses any of these flags along with a
different tid cached field? Would it just copy the tid value to argument passed
pointer? Can we have any synchronization issue with it?

2. What about fork handler, should it ignore it? 

3. What about malloc internal locks so malloc is consistent on new process?

4. What about pthread robust list? 

5. What if CLONE_THREAD is specified? Should we clear or ignore it? CLONE_VM
also poses some issues.

I still think that we already have a good interface to interact along with
clone and it the execv function family.

-- 
You are receiving this mail because:
You are on the CC list for the bug.