[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#3549) HEAD/2.3 cancel exop is broken?

Full_Name: Howard Chu
Version: HEAD,2.3
OS: Linux 
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (
Submitted by: hyc

It appears that the code for the cancel exop in cancel.c is broken.

If a cancel is processed for a pending operation, then it will probably return
safely. (Of course, it is impossible for a cancel to be processed once any
operations are pending.)

If the target operation is active on the current connection, the cancel
operation will go into an infinite loop. It sets op->o_cancel = SLAP_CANCEL_REQ
and waits for that to be changed, but nothing else in the codebase ever sets

If the target operation is not found on the current connection, a search is
performed for any backend that implements the cancel function. If no backends
handle it, then a NO_SUCH_OPERATION result is returned. That result is probably
correct, but I don't see why this check is done at all. There are no hidden
operations, any operation on that connection will live on either the pending
list or the active list.

The check for op->o_cancel != SLAP_CANCEL_NONE is using the wrong op structure.
It's using the current op which is the Cancel Request itself; it should be
checking the target op of the Cancel.

Looks like a similar infinite loop occurs in connection.c...