From 5b4b8126de52c8a895094cfea61724a91e179e71 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Mon, 6 Feb 2012 12:24:49 -0500 Subject: [PATCH] Loop on filtering SSL reads until we are blocked or exhausted. This is not a perfect fix, but it's much much better than the current buggy behavior, which could lead to filtering SSL connections that just stopped reading. Based on ideas by Maseeb Abdul Qadir and Mark Ellzey. --- bufferevent_openssl.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/bufferevent_openssl.c b/bufferevent_openssl.c index d703279c..ea9d0d65 100644 --- a/bufferevent_openssl.c +++ b/bufferevent_openssl.c @@ -781,6 +781,23 @@ consider_reading(struct bufferevent_openssl *bev_ssl) * already been done, since OpenSSL went and read a * whole SSL record anyway. */ n_to_read = SSL_pending(bev_ssl->ssl); + + /* XXX This if statement is actually a bad bug, added to avoid + * XXX a worse bug. + * + * The bad bug: It can potentially cause resource unfairness + * by reading too much data from the underlying bufferevent; + * it can potentially cause read looping if the underlying + * bufferevent is a bufferevent_pair and deferred callbacks + * aren't used. + * + * The worse bug: If we didn't do this, then we would + * potentially not read any more from bev_ssl->underlying + * until more data arrived there, which could lead to us + * waiting forever. + */ + if (!n_to_read && bev_ssl->underlying) + n_to_read = bytes_to_read(bev_ssl); } if (!bev_ssl->underlying) { -- 2.40.0