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] |
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] |