On Tue, 17 May 2011, Scott Schaefer <saschae...@neurodiverse.org> wrote:
> I am a bit confused... I am certainly no Helgrind expert [indeed, I had
> never heard of it until I first read your report), and I will concede
> that it may know more about C than I do. However, this certainly
> appears to me to be a false positive.
>
> The variable err_fns is declared as:
> static const ERR_FNS *err_fns = NULL;
>
> Your subject line states "err_fns_check() has a race if a pointer
> assignment is not atomic". Except, because the assignment is inside of
> CRYPTO_w_lock(),CRYPTO_w_unlock(), no race condition exists (assuming
> these two functions are implemented correctly).
If that function was the only one using the function pointer in question then
that analysis would be correct.
const ERR_FNS *ERR_get_implementation(void)
{
err_fns_check();
return err_fns;
}
However it's expected that some other functions such as the above which rely
on it. Imagine an architecture which has 64bit pointers but only 32bit
atomicity for memory writes. If one thread writes a value to err_fns and gets
interrupted before completing the operation then another thread could return
from the first line of err_fns_check() and allow ERR_get_implementation() to
return data from a half-written memory location.
I could be wrong in this analysis, it would be good if someone who knows more
about Valgrind than I do could check this out.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
