On Nov 21, 2008, at 12:01 AM, Massimiliano Pala wrote:
Actually, it seems that the dynamic functions are never called... :(
I can assure you from my work on Apache 2.2.10 that the CHIL engine calls the dynamic locking upcalls many times. It seems to be the only thing in the OpenSSL distribution that uses them though.
Are you by any chance passing the THREAD_LOCKING control command to the engine? In engines/e_chil.c:736:
case HWCRHK_CMD_THREAD_LOCKING:
CRYPTO_w_lock(CRYPTO_LOCK_ENGINE);
disable_mutex_callbacks = ((i == 0) ? 0 : 1);
CRYPTO_w_unlock(CRYPTO_LOCK_ENGINE);
break;
which I take to read "if the input i is 0, then set
disable_mutex_callbacks to 0, any other value, set it to 1. Then, in
hwcrhk_init at line 580 (in trunk):
if (disable_mutex_callbacks == 0)
{
if (CRYPTO_get_dynlock_create_callback() != NULL &&
CRYPTO_get_dynlock_lock_callback() != NULL &&
CRYPTO_get_dynlock_destroy_callback() != NULL)
{
hwcrhk_globals.mutex_init = hwcrhk_mutex_init;
hwcrhk_globals.mutex_acquire = hwcrhk_mutex_lock;
hwcrhk_globals.mutex_release = hwcrhk_mutex_unlock;
hwcrhk_globals.mutex_destroy = hwcrhk_mutex_destroy;
}
}
which means the function pointers that use the dynamic locks only get
passed to the Hardware Crypto Hook library when that flags is 0. My
coffee-starved brain would assume that 0 means "no" and !0 means "yes"
when specifying whether to use thread locking, but it seems to be the
other way around here. Perhaps that should be documented in the
description of the control.
FWIW Apache runs just fine, with dynamic locks and CHIL, in a multithreaded setup, without setting THREAD_LOCKING on the engine. I just got back from watching it run for a week with 8192 threads, 256 threads to a child process and it was rock solid.
S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
smime.p7s
Description: S/MIME cryptographic signature
