[Date Prev][Date Next]
Re: commit: ldap/servers/slapd/back-bdb proto-bdb.h search.c
> There are other issues in this code now as well. "sop" is a shared
> resource, many operations may be generating psearch results
> simultaneously. It was intended to be read-only, but there are now
> several places in search.c that cause fields in sop to be modified. sop
> now either needs to be locked, or a local copy needs to be made.
> (Probably the latter is best.)
I'll experiment with the former first 'cause it can be done simply by
changing read locking to the pslist to writing locking.
> Also, all of the slap_build_XXX_ctrl functions need to use an explicit
> op->o_tmpmemctx, (i.e., the tmpmemctx from the currently running
> operation) not the tmpmemctx in sop. Again, since sop is shared and the
> sl_mem functions assume that only one thread has access to the
> tmpmemctx, this will get corrupted.
> I suspect that the "locker" needs to come from the op->o_private as
> well, when present; otherwise certain entrycache DB locks could deadlock.
I've prepare a patch for this basically doing a check to op->o_private
whether to get a new locker or the one in the bdb_op_info. Will post soon.