BUG/MEDIUM: Cur/CumSslConns counters not threadsafe.

CurSslConns inc/dec operations are not threadsafe. The unsigned CurSslConns
counter can wrap to a negative value. So we could notice connection rejects
because of MaxSslConns limit artificially exceeded.

CumSslConns inc operation are also not threadsafe so we could miss
some connections and show inconsistenties values compared to CumConns.

This fix should be backported to v1.8.
This commit is contained in:
Emeric Brun 2018-10-10 14:51:02 +02:00 committed by Willy Tarreau
parent 0b25d5e99f
commit 7ad43e7928

View File

@ -495,7 +495,7 @@ static void ssl_async_fd_free(int fd)
/* Now we can safely call SSL_free, no more pending job in engines */
SSL_free(ssl);
sslconns--;
HA_ATOMIC_SUB(&sslconns, 1);
HA_ATOMIC_SUB(&jobs, 1);
}
/*
@ -5032,8 +5032,8 @@ static int ssl_sock_init(struct connection *conn)
/* leave init state and start handshake */
conn->flags |= CO_FL_SSL_WAIT_HS | CO_FL_WAIT_L6_CONN;
sslconns++;
totalsslconns++;
HA_ATOMIC_ADD(&sslconns, 1);
HA_ATOMIC_ADD(&totalsslconns, 1);
return 0;
}
else if (objt_listener(conn->target)) {
@ -5083,8 +5083,8 @@ static int ssl_sock_init(struct connection *conn)
conn->flags |= CO_FL_EARLY_SSL_HS;
#endif
sslconns++;
totalsslconns++;
HA_ATOMIC_ADD(&sslconns, 1);
HA_ATOMIC_ADD(&totalsslconns, 1);
return 0;
}
/* don't know how to handle such a target */
@ -5728,7 +5728,7 @@ static void ssl_sock_close(struct connection *conn) {
#endif
SSL_free(conn->xprt_ctx);
conn->xprt_ctx = NULL;
sslconns--;
HA_ATOMIC_SUB(&sslconns, 1);
}
}