Work around OpenSSL read-ahead induced deadlock

Pending unprocessed data in an SSL object causes SSL_write() to return
SSL_WANTS_READ. In case the application only wanted to send messages
(not receive), that would cause XCM to wait for new data, when further
SSL_write() operations may be possible.

This patch makes sure XCM asks OpenSSL to process any pending
(buffered) unprocessed TLS data, even though the application is only
asking to send messages.

An alternative workaround for this issue would be to turn off OpenSSL
read-ahead. Such a move would cause a significant loss of TLS
transport performance, due to an increased number of system calls.

Signed-off-by: Mattias Rönnblom <[email protected]>

libxcm/tp/tls/xcm_tp_btls.c

@@ -1116,7 +1116,15 @@ static void conn_update(struct xcm_socket *s)
 	if (s->condition == 0)
 	    break;
 	else if (s->condition&XCM_SO_RECEIVABLE &&
+		 SSL_pending(bts->conn.ssl) > 0)
+	    ready = true;
+	else if (SSL_pending(bts->conn.ssl) == 0 &&
 		 SSL_has_pending(bts->conn.ssl))
+	    /* Unprocessed data (a result of OpenSSL read-ahead) may
+	       lead to SSL_WANTS_READ even at SSL_write(),
+	       seemingly. This in turn may lead to a dead lock, so
+	       it's better to turn this into processed data even
+	       though application isn't waiting for XCM_SO_RECEIVABLE. */
 	    ready = true;
 	else if (bts->conn.ssl_condition == 0)
 	     /* No SSL_read()/write() issued */