This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] Fix double-checked locking in _res_hconf_reorder_addrs [BZ #19074]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Siddhesh Poyarekar <sid at reserved-bit dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 14 Oct 2015 15:07:27 +0200
- Subject: Re: [PATCH v3] 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> <5613DBB6 dot 8020109 at redhat dot com> <1444213721 dot 25110 dot 68 dot camel at localhost dot localdomain> <56152831 dot 7020707 at redhat dot com> <1444317267 dot 25110 dot 195 dot camel at localhost dot localdomain> <561BD573 dot 40003 at redhat dot com> <1444824669 dot 25110 dot 396 dot camel at localhost dot localdomain>
On 10/14/2015 02:11 PM, Torvald Riegel wrote:
>> > - /* Recheck, somebody else might have done the work by now. */
>> > - if (num_ifs <= 0)
>> > + /* Recheck, somebody else might have done the work by now. A
>> > + relaxed load is sufficient because we have the lock, and
>> > + num_ifs is only updated under the lock. */
> That's not really the reason why the relaxed MO load is okay. You cite
> just concurrent updates to num_ifs, but the relation to these is not
> affected by the MO here. The MOs are about ordering, so you'd need a
> reason related to ordering here, informally.
> I would instead just refer to point (3) below.
Right, we don't need a non-atomic load here, but you wanted one in case
of future changes.
I'll commit this:
/* Recheck, somebody else might have done the work by now. No
ordering is required for the load because we have the lock,
and num_ifs is only updated under the lock. Also see (3) in
the analysis below. */
I've incorporated your other changes.
Thanks,
Florian