summaryrefslogtreecommitdiff
path: root/bufferevent_openssl.c
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2012-02-06 12:24:49 -0500
committerNick Mathewson <nickm@torproject.org>2012-02-06 12:37:40 -0500
commit5b4b8126de52c8a895094cfea61724a91e179e71 (patch)
tree7131134518abf0bdef309f62994dec346b0b6837 /bufferevent_openssl.c
parentd84d917099e9e31df62ab4461019bd7613dc24f1 (diff)
downloadlibevent-5b4b8126de52c8a895094cfea61724a91e179e71.tar.gz
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.
Diffstat (limited to 'bufferevent_openssl.c')
-rw-r--r--bufferevent_openssl.c17
1 files changed, 17 insertions, 0 deletions
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) {