This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] #13594: Avoid race in nscd
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Andreas Jaeger <aj at suse dot com>
- Cc: libc-alpha at sourceware dot org, Jeffrey Yasskin <jyasskin at google dot com>, Richard Smith <richardsmith at google dot com>, "Carlos O'Donell" <carlos at systemhalted dot org>, Roni Simonian <ronis at google dot com>
- Date: Fri, 8 Mar 2013 15:57:07 -0800
- Subject: Re: [PATCH] #13594: Avoid race in nscd
- References: <4FB166E3.10808@suse.de> <CADZpyizJF5xz1q0wXSUvhfFf647FgNSrdeBXBz_NrOsGL7gSvA@mail.gmail.com><4FB1725C.7020508@suse.com>
On Mon, May 14, 2012 at 2:00 PM, Andreas Jaeger <aj@suse.com> wrote:
We've just been hit by this bug. Thanks for the fix!
> On 05/14/2012 10:37 PM, Carlos O'Donell wrote:
>> Is this sufficient to guarantee atomicity? Is it because we use the
>> *_acq sematic atomic that it works?
>
>
> The acq code checks first that the value is 0 - and only then changes it. So
> with setting it to 0 we release the lock.
In reviewing the patch, Richard Smith noted the same problem Carlos did.
Quoting Jeffrey Yasskin:
The patch is wrong. Among more exotic problems, the compiler could emit
the 'mov' instruction that stores 0 to the lock before the read from
map->head->extra_data[NSCD_HST_IDX_CONF_TIMESTAMP], allowing another
thread to get in and change it.
A release barrier is required here. I'll send a follow patch.
Thanks,
--
Paul Pluzhnikov