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

[Mike Frysinger <vapier at gentoo dot org>]

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.

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 ?

> +  /* grab ld.so lock BEFORE switching to malloc_atfork */

comment style is incorrect

> +      /* unlock ld.so last, because we locked it first */

comment style is wrong here too
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.