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>

1 files changed, 9 insertions, 0 deletions

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 *