[Date Prev][Date Next]
Re: ldap_new_connection() mutex issue
> firstname.lastname@example.org 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.
OK, I've checked.
ldap_new_connection() must be called holding ld_req_mutex; ld_res_mutex
must be also held if connection != 0 or bind != NULL
ldap_new_connection() is called by ldap_send_server_request() with connect
= 1; this, in turn, is called holding ld_req_mutex but not ld_res_mutex
ldap_new_connection() is also called by:
- ldap_open_defconn() with connect = 1; this in turn must be called
- ldap_init_fd() with connect = 0 and bind = NULL; this function does not
hold any mutex (nor any is required since the LDAP structure has just been
created and thus cannot be shared)
- ldap_open_internal_connection() (same as above; never used in OpenLDAP
I guess we need to eliminate the unlock/lock of ld_res_mutex and inform
ldap_new_connection() about whether ld_req_mutex is locked or not...