Re: [PATCH] nptl: Fix deadlock on atfork handler which calls dlclose (BZ#24595)

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

On 08/07/2019 10:11, Florian Weimer wrote:
> I have thought about this some more and now wonder if we should add a
> generic copy-on-write list which supports deletions in the middle.
> 
> We could use it for an internal copy of _IO_list_all (which is
> unfortunately part of the ABI), too.  It would help with code that has
> to deal with callbacks where the callbacks can acquire the list lock or
> modify the list.
> 
> Thanks,
> Florian
> 

For this specific usage I think dynarray or even a copy-on-write is poor
choice due some factors: 

  - Iteration is done through pointer increment, which make callback that change
    the list itself invalidate the associated index values. We can add a function
    to retrieve the next element based on current one, but I do think a better
    alternative is just to use a double-linked list.

  - dlclose actually removes elements, so the array will need to be resized
    and the elements changed internally.  A simpler list make this easier.

  - The copy-on-write does not really solve the issue where a dlclose should
    prevent a handler further in iteration list to be run (as you noted
    before).

As Carlos has suggested, I think we can use the same strategy as for atexit
handlers and release the lock while running the callbacks.  Along with a
double linked-list, the list should be kept concise as long as it is invalid 
to dlclose itself.  

It should be safe also call pthread_atfork from a registered callback,
although it is up to the caller to handle the resulting list state regarding
callback call.  Since the new element is added on the end of the list, the
prepare handler won't see the new element (since it ran in reverse order),
however both the parent and child will.

I have implemented this new scheme on a personal branch [1].

[1] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/bz24595