This is an automated email from the git hooks/post-receive script.
tbordaz pushed a commit to branch 389-ds-base-1.4.3 in repository 389-ds-base.
The following commit(s) were added to refs/heads/389-ds-base-1.4.3 by this push: new 285fd0d Ticket 51035 - Heavy StartTLS connection load can randomly fail with err=1 285fd0d is described below
commit 285fd0dfe9d35d6339eb6e7968d56638b8613df1 Author: Thierry Bordaz tbordaz@redhat.com AuthorDate: Mon Apr 20 15:17:03 2020 +0200
Ticket 51035 - Heavy StartTLS connection load can randomly fail with err=1
Bug Description: startTls pushes a network layer on top of the connection. So when processing startTLS, there should not be a pending operation else there is a risk that the operation sends back data on moving network layer. When startTls detects a pending operation it aborts startTls. However if a new operation is received while processing startTls, the operation is pending but can not be read because startTls holds c_mutex.
Fix Description: In case of unread pending operation, relax the control and just log an information message.
https://pagure.io/389-ds-base/issue/51035
Reviewed by: Mark Reynolds, William Brown
Platforms tested: F30
Flag Day: no
Doc impact: no --- ldap/servers/slapd/operation.c | 4 ++-- ldap/servers/slapd/start_tls_extop.c | 30 +++++++++++++++++++++++++----- 2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/ldap/servers/slapd/operation.c b/ldap/servers/slapd/operation.c index 8590e2d..ff16cd9 100644 --- a/ldap/servers/slapd/operation.c +++ b/ldap/servers/slapd/operation.c @@ -150,8 +150,8 @@ operation_init(Slapi_Operation *o, int flags) /* We can't get rid of this til we remove the operation stack. */ memset(o, 0, sizeof(Slapi_Operation)); o->o_ber = ber; - o->o_msgid = -1; - o->o_tag = LBER_DEFAULT; + o->o_msgid = -1; /* if changed please update start-tls that test this value */ + o->o_tag = LBER_DEFAULT; /* if changed please update start-tls that test this value */ o->o_status = SLAPI_OP_STATUS_PROCESSING; slapi_sdn_init(&(o->o_sdn)); o->o_authtype = NULL; diff --git a/ldap/servers/slapd/start_tls_extop.c b/ldap/servers/slapd/start_tls_extop.c index bfa32b7..f415c41 100644 --- a/ldap/servers/slapd/start_tls_extop.c +++ b/ldap/servers/slapd/start_tls_extop.c @@ -188,11 +188,31 @@ start_tls(Slapi_PBlock *pb) /* Check whether the Start TLS request can be accepted. */ if (connection_operations_pending(conn, pb_op, 1 /* check for ops where result not yet sent */)) { - slapi_log_err(SLAPI_LOG_PLUGIN, "start_tls", - "Other operations are still pending on the connection.\n"); - ldaprc = LDAP_OPERATIONS_ERROR; - ldapmsg = "Other operations are still pending on the connection."; - goto unlock_and_return; + for (Operation *op = conn->c_ops; op != NULL; op = op->o_next) { + if (op == pb_op) { + continue; + } + if ((op->o_msgid == -1) && (op->o_tag == LBER_DEFAULT)) { + /* while processing start-tls extop we also received a new incoming operation + * As this operation will not processed until start-tls completes. + * Be fair do not consider this operation as a pending one + */ + slapi_log_err(SLAPI_LOG_CONNS, "start_tls", + "New incoming operation blocked by start-tls, Continue start-tls (conn=%"PRIu64").\n", + conn->c_connid); + continue; + } else { + /* It is problematic, this pending operation is processed and + * start-tls can push new network layer while the operation + * send result. Safest to abort start-tls + */ + slapi_log_err(SLAPI_LOG_CONNS, "start_tls", + "Other operations are still pending on the connection.\n"); + ldaprc = LDAP_OPERATIONS_ERROR; + ldapmsg = "Other operations are still pending on the connection."; + goto unlock_and_return; + } + } }
389-commits@lists.fedoraproject.org