This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCHv6] Fix _dl_profile_fixup data-dependency issue (Bug 23690)
- From: Tulio Magno Quites Machado Filho <tuliom at linux dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, John David Anglin <dave dot anglin at bell dot net>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>, "Carlos O'Donell" <carlos at redhat dot com>
- Date: Fri, 30 Nov 2018 18:09:02 -0200
- Subject: Re: [PATCHv6] Fix _dl_profile_fixup data-dependency issue (Bug 23690)
- References: <4283ed6b-f41b-336b-95ae-0e39efadf8f3@redhat.com> <20181130162259.32512-1-tuliom@linux.ibm.com> <35e55a32-0ef1-1438-aabb-002cc8d160f4@redhat.com>
Carlos O'Donell <carlos@redhat.com> writes:
> On 11/30/18 11:22 AM, Tulio Magno Quites Machado Filho wrote:
>> There is a data-dependency between the fields of struct l_reloc_result
>> and the field used as the initialization guard. Users of the guard
>> expect writes to the structure to be observable when they also observe
>> the guard initialized. The solution for this problem is to use an acquire
>> and release load and store to ensure previous writes to the structure are
>> observable if the guard is initialized.
>>
>> The previous implementation used DL_FIXUP_VALUE_ADDR (l_reloc_result->addr)
>> as the initialization guard, making it impossible for some architectures
>> to load and store it atomically, i.e. hppa and ia64, due to its larger size.
>>
>> This commit adds an unsigned int to l_reloc_result to be used as the new
>> initialization guard of the struct, making it possible to load and store
>> it atomically in all architectures. The fix ensures that the values
>> observed in l_reloc_result are consistent and do not lead to crashes.
>> The algorithm is documented in the code in elf/dl-runtime.c
>> (_dl_profile_fixup). Not all data races have been eliminated.
>>
>> Tested with build-many-glibcs and on powerpc, powerpc64, and powerpc64le.
>
> Perfect. Please commit to master :-)
>
> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Pushed as e5d262effe3a87164308a3f37e61b32d0348692a.
Thanks!
--
Tulio Magno