[RFC][BZ #1874] Fix assertion triggered by thread/fork interaction

[Ondřej Bílka]

On Thu, Jan 02, 2014 at 05:18:22PM -0500, Mike Frysinger wrote:
> On Wednesday 09 October 2013 16:05:34 Ondřej Bílka wrote:
> > Details:
> > 
> > If a thread happens to hold dl_load_lock and have r_state set to RT_ADD
> > or RT_DELETE at the time another thread calls fork(), then the child exit
> > code from fork (in nptl/sysdeps/unix/sysv/linux/fork.c in our case)
> > re-initializes dl_load_lock but does not restore r_state to RT_CONSISTENT.
> > If the child subsequently requires ld.so functionality before calling
> > exec(), then the assertion will fire.
> > 
> > The patch acquires dl_load_lock on entry to fork() and releases it on exit
> > from the parent path.  The child path is initialized as currently done.
> > This is essentially pthreads_atfork, but forced to be first because the
> > acquisition of dl_load_lock must happen before malloc_atfork is active
> > to avoid a deadlock.
> > "
> 
> doesn't seem right that we grab the lock and then just reset it in the child ?  
> seems like you should just unlock it rather than reset it in the child.
>
That part looks ok as without locking you could get inconsistent linker structures. 

> i'm also wary of code that already grabs a lot of locks trying to grab even 
> more.  the code paths that already grab the IO locks ... can they possibly 
> grab this one too ?  like a custom format handler that triggers loading of 
> libs ?
>
Do you haave a better solution? I send this to decide what to do with
this bug. I would not be surprised if we decided that it is invalid as
threads with fork cause problems in general.