On Thu, Nov 10, 2005, Steffen Fiksdal wrote:
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..
On 0.9.8 that macro calls BN_MONT_CTX_set_locked(). Can you put some locks in
there so a lock is always called and see if that helps?
I serialized the whole BN_MONT_CTX_set_locked() function, but it still
fails.
THe BN_MONT_CTX_set_locked is not always called because sometimes
the _method_mod_n is NOT NULL.
Because the BN_MONT_CTX_set_locked seems to work, this race condition must
be for the times the BN_MONT_CTX_set_locked() is not called.
I do not have knowledge about the details here, but I report what I
experience..
I have the sequence for when it fails. First I print "Going MONT_HELPER"
just before the macro is called, then I print "Went MONT_HELPER" just
after the macro is finished. I also print the pre_cond and _method_mod_n
values. The result was the following with 2 threads:
Going MONT_HELPER
pre_cond=2
_method_mod_n == NULL
Going MONT_HELPER
pre_cond=2
_method_mod_n != NULL
Went MONT_HELPER
Went MONT_HELPER.
The times it works ok, one thread goes through MONT_HELPER without any
disturbance from other threads. In this error situation this was not the
case. For the second thread in the output the BN_MONT_CTX_set_locked()
will not be called.
Best Regards
Steffen Fiksdal
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
