This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |