Fix TLS write busy-spin on SSL_ERROR_WANT_READ
A TLS sendData() failing with SSL_ERROR_WANT_READ (mid-handshake application data, or a post-handshake session ticket exchange) has nothing to do with write-readiness, but resetSocket() kept re-arming EPOLLWRNORM anyway - an already-writable TCP socket fires that immediately, so the retry loop spun the CPU as fast as it could until the connection was eventually dropped, without ever reading the peer's first command. Confirmed via a 15GB+ debug log from one stuck connection. sendNeedsRead() lets Socket now tell the difference and wait for a real EPOLLIN instead of busy-retrying.
This commit is contained in:
1 parent
c3e8d70774
commit
2676aaf84c
6 files changed
+68
-1
No files matched your search
@@ -59,6 +59,19 @@ namespace core {
|
||||
void registerSocket(int fd);
|
||||
void acceptSocket();
|
||||
|
||||
protected:
|
||||
// Set by sendData() when the last SSL_write() failed specifically
|
||||
// with SSL_ERROR_WANT_READ (needs a READ to make progress - e.g.
|
||||
// mid-handshake application data, or a post-handshake session
|
||||
// ticket exchange) rather than any other reason. TCPSocket::
|
||||
// sendNeedsRead() reads this (protected, so a subclass can reach
|
||||
// it directly) to tell Socket::writeSocket()/resetSocket() not to
|
||||
// busy-spin retrying the write via EPOLLWRNORM - see their own
|
||||
// doc comments for the confirmed real damage (a 15GB+ debug log,
|
||||
// and every affected connection dropped before ever reading the
|
||||
// client's first command) this caused when unaddressed.
|
||||
bool lastSendWantedRead = false;
|
||||
|
||||
private:
|
||||
char *sip_cacert = (char *)"../testkeys/certs/pbxca.crt";
|
||||
char *sip_cert = (char *)"../testkeys/certs/pbxserver.crt";
|
||||
|
||||
Reference in new issue
Block a user