This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix double-checked locking in _res_hconf_reorder_addrs [BZ #19074]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Siddhesh Poyarekar <sid at reserved-bit dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: Torvald Riegel <triegel at redhat dot com>
- Date: Tue, 6 Oct 2015 16:33:26 +0200
- Subject: Re: [PATCH] Fix double-checked locking in _res_hconf_reorder_addrs [BZ #19074]
- Authentication-results: sourceware.org; auth=none
- References: <5613BF47 dot 9000503 at redhat dot com> <5613D5F5 dot 7020603 at reserved-bit dot com>
On 10/06/2015 04:08 PM, Siddhesh Poyarekar wrote:
> On Tuesday 06 October 2015 06:02 PM, Florian Weimer wrote:
>> This addresses a data race in libresolv. The race is not entirely
>> benign, it could cause programs to access a partially initialized
>> ifaddrs array.
>>
>> I made sure this compiles on x86_64, but this code is difficult to test.
>>
>> A potential follow-up optimization would be to move the socket creation
>> under the lock. No need to create a socket if we lose the race to the lock.
>
> The code needs verbose comments to describe the rationale for the
> ordering semantics you've decided on.
Do we have documentation on the wiki for common concurrency idioms?
It's probably best to document things that work and way, and stick to
that, instead of using ad-hoc schemes all over the place. (I think the
code I showed is sufficiently close to the usual double-checked locking
idiom, except that the guarded section may run multiple times.)
Florian