A recent problem wrt multithreaded SSL use was causing a deadlock under
Unix after some use. This was traced to a call in SSL_CTX_add_session()
which locks a mutex and then calls SSL_CTX_remove_session() which also
tries to lock the same mutex, in the same thread.
On this platform (Linux) the type of mutex used causes a deadlock if a
"double lock" of this kind is attempted. This actually follows the
example in crypto/threads which under Linux uses a "fast mutex".
A quick look through the code in ssl/ and I spotted one other case. I've
checked in fixes for both cases. There may be other cases I've missed:
they aren't easy to spot.
As I see it there are several ways to proceed.
1. Decide that multiple locking is a bug (as the stuff in crypto/threads
suggests) and fix any cases found.
2. Decide that multiple locking is not a bug and fix the locking code to
wrap the locking callbacks to support multiple locking.
3. Decide that double locking is not a bug and expect the supplied
locking callbacks to handle multiple locking themselves: this will mean
that crypto/threads needs updating. Under Linux this is just a case of
using recursive mutexes, on other platforms this may not so easy.
If it is decided that multiple locking is not a bug then mutexes should
only unlock after the same number of calls to unlock as were given to
lock.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
