This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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]

[PATCH][BZ #5741] fix segfaul in __libc_dlopen_mode


This is a race condition between the PLT call stubs and _dl_fixup on the
contents of  the PLT entry. We have only seen this on out-of-order
machines with deep instruction queues like POWER5 and POWER5+. 

In this case case multiple threads are going through pthread_exit, 
__pthread_unwind, _Unwind_ForcedUnwind, pthread_cancel_init, __libc_dlopen_mode.
The 1st thread hits the unresolved PLT entry for __libc_dlopen_mode and ends up
in _dl_fixup to update that PLT entry. Other threads may be going through the
same call stubs on other cores and SMT threads.

Because POWER5 is out-of-order the load of the plt->fd_toc may actually execute
before the load of the plt->func executes. In this worst case timing the unlucky
thread may see the unresolved plt->toc value (which in NULL) and the updated
plt-func pointer. The results is a segfault when __libc_dlopen_mode tries to use
the toc pointer to reference static variables.

The patch changes the elf_machine_fixup_plt to flush the toc update out to main
storage before the new function pointer is stored. This insures that the toc load
will be delayed until after the function pointer load.

Attachment: ppc64-dl-machine-20080201.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]