[email protected] writes: > ldap_new_connection(), if ( connect ) and lconn_server->lud_exts contain > the tls ext, first unlocks and then re-locks ld_req_mutex and > ld_res_mutex. As far as I understand, while the former is actually held > by the caller(s) of ldap_new_connection(), the latter is not. If this > analysis is correct, I'll post an ITS.
It is only relevant when the 'connect' argument is != 0: In request.c:ldap_send_server_request() and open.c:ldap_open_defconn(). ldap_result() locks ldap_res_mutex, which is one road to the first case. Hopefully all roads do something similar, I haven't checked. However, open.c doesn't lock either mutex: /* Caller should hold the req_mutex if simultaneous accesses are possible */ int ldap_open_defconn( LDAP *ld ) Looks like the "if" in the comment at best should have listed some more cases, to avoid code paths into using these mutexes. -- Hallvard
