On Thu, Nov 10, 2005, Steffen Fiksdal wrote:
On Thu, Nov 10, 2005, Steffen Fiksdal wrote:
I have investigated some more on this issue.
I have traced the problem down to the MONT_HELPER call int the
RSA_eay_public_decrypt function in file rsa_eay.c.
If I mutex this call everything works fine, if I don't the verifications
failes in a few occations.
So it seems that the MONT_HELPER has a threading issue ?
What OS are you using and is it multi processor or does it use
hyperthreading?
It seems strange that this small macro should create any threading issues.
I use Linux 2.4.21-27 SMP. It has two Intel processors, but only one is
physically in use. No hyperthreading.
I should try this on a non-SMP kernel and check ?
Maybe it's the pthread implementation that does not cope well with SMP.
My reason for asking is that there has been some discussion suggesting that
OpenSSLs use of DCLP (double-checked locking pattern) may not be valid for
some environments. IIRC multi processors and hyperthreading were two cases
which might cause problems.
No one has so far come up with a concrete example of it failing though.
I have tried to get this error on my other linux box, a uniprocessor non
SMP Linux kernel, without luck.
So I experience the error in a few occations on the SMP kernel, but not on
the uniprocessor non SMP Linux kernel.
When I mutex the MONT_HELPER call myself by wrapping the macro with a
CRYPTPO_lock(), I do not get the error on the SMP kernel.
This can have several reasons, but it is kind of strange..
Best Regards,
Steffen Fiksdal
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
