summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDavid Goulet <dgoulet@torproject.org>2017-11-08 09:44:39 -0500
committerDavid Goulet <dgoulet@torproject.org>2017-11-08 09:44:39 -0500
commitdcabf801e52a83e2c3cc23ccc1fa906582a927d6 (patch)
tree298f6cc999b675a78d7333b41d0ef18290ebb444
parente5a83062ed4e9e6b908efc6b75f13ab269f97377 (diff)
downloadtor-dcabf801e52a83e2c3cc23ccc1fa906582a927d6.tar.gz
tor-dcabf801e52a83e2c3cc23ccc1fa906582a927d6.zip
sched: Ignore closed channel after flushing cells
The flush cells process can close a channel if the connection write fails but still return that it flushed at least one cell. This is due because the error is not propagated up the call stack so there is no way of knowing if the flush actually was successful or not. Because this would require an important refactoring touching multiple subsystems, this patch is a bandaid to avoid the KIST scheduler to handle closed channel in its loop. Bandaid on #23751. Signed-off-by: David Goulet <dgoulet@torproject.org>
-rw-r--r--changes/bug237516
-rw-r--r--src/or/scheduler_kist.c9
2 files changed, 15 insertions, 0 deletions
diff --git a/changes/bug23751 b/changes/bug23751
new file mode 100644
index 0000000000..2fd7021664
--- /dev/null
+++ b/changes/bug23751
@@ -0,0 +1,6 @@
+ o Minor bugfixes (scheduler, channel):
+ - Ignore channels that have been closed while flushing cells. This can
+ happen if the write on the connection fails leading to the channel being
+ closed while in the scheduler loop. This is not a complete fix, it is a
+ bandaid until we are able to refactor those interactions. Fixes bug
+ 23751; bugfix on 0.3.2.1-alpha.
diff --git a/src/or/scheduler_kist.c b/src/or/scheduler_kist.c
index a3b74e8cc9..d1726ba345 100644
--- a/src/or/scheduler_kist.c
+++ b/src/or/scheduler_kist.c
@@ -598,6 +598,15 @@ kist_scheduler_run(void)
if (socket_can_write(&socket_table, chan)) {
/* flush to channel queue/outbuf */
flush_result = (int)channel_flush_some_cells(chan, 1); // 1 for num cells
+ /* XXX: While flushing cells, it is possible that the connection write
+ * fails leading to the channel to be closed which triggers a release
+ * and free its entry in the socket table. And because of a engineering
+ * design issue, the error is not propagated back so we don't get an
+ * error at this poin. So before we continue, make sure the channel is
+ * open and if not just ignore it. See #23751. */
+ if (!CHANNEL_IS_OPEN(chan)) {
+ continue;
+ }
/* flush_result has the # cells flushed */
if (flush_result > 0) {
update_socket_written(&socket_table, chan, flush_result *