This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [BZ #19329] Fix race during concurrent dlopen and pthread_create
- From: Szabolcs Nagy <nsz at port70 dot net>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Ilya Palachev <i dot palachev at samsung dot com>, libc-alpha at sourceware dot org, triegel at redhat dot com, siddhesh dot poyarekar at linaro dot org, szabolcs dot nagy at arm dot com, v dot barinov at samsung dot com
- Date: Tue, 29 Dec 2015 21:53:48 +0100
- Subject: Re: [PATCH] [BZ #19329] Fix race during concurrent dlopen and pthread_create
- Authentication-results: sourceware.org; auth=none
- References: <1451385533-9485-1-git-send-email-i dot palachev at samsung dot com> <5682D599 dot 9010607 at redhat dot com>
* Florian Weimer <fweimer@redhat.com> [2015-12-29 19:48:57 +0100]:
> On 12/29/2015 11:38 AM, Ilya Palachev wrote:
> > + listp->slotinfo[idx].gen = atomic_increment_val(&GL(dl_tls_generation));
>
> Space after atomic_increment_val. And I think it's a legacy macro, not
> one of the new C11 macros. It's surprising that atomic access is not
> needed in any other places. Why is this so?
>
using atomic read during pthread_create is missing from the patch
as well as the use of atomics for slotinfo[idx] members.
a correct fix is non-trivial and will add several atomic memory ops.
> Does the counter now need overflow protection on 32-bit architectures
> because it is incremented more often?
it already had overflow protection, the patch broke that though