kist: Don't try to flush empty outbuf

It is possible that a scheduled channel ended up with 0 bytes in its
outbuf after the scheduling loop and having an outbuf table entry
indicating that we need to flush bytes on the wire after the loop.

This lead to attempt to write 0 bytes up to the TLS layer that would
prevent such action.

All in all, this fixes wasted CPU cycles on attempting to flush nothing.

Fixes #40548

Signed-off-by: David Goulet <dgoulet@torproject.org>

1 files changed, 10 insertions, 2 deletions

diff --git a/src/core/or/scheduler_kist.c b/src/core/or/scheduler_kist.c
index eba55f6497..52bc62f1b4 100644
--- a/src/core/or/scheduler_kist.c
+++ b/src/core/or/scheduler_kist.c
@@ -465,9 +465,17 @@ MOCK_IMPL(int, channel_should_write_to_kernel,
 MOCK_IMPL(void, channel_write_to_kernel, (channel_t *chan))
 {
   tor_assert(chan);
+
+  /* This is possible because a channel might have an outbuf table entry even
+   * though it has no more cells in its outbuf. Just move on. */
+  size_t outbuf_len = channel_outbuf_length(chan);
+  if (outbuf_len == 0) {
+    return;
+  }
+
   log_debug(LD_SCHED, "Writing %lu bytes to kernel for chan %" PRIu64,
-            (unsigned long)channel_outbuf_length(chan),
-            chan->global_identifier);
+            (unsigned long) outbuf_len, chan->global_identifier);
+
   /* Note that 'connection_handle_write()' may change the scheduler state of
    * the channel during the scheduling loop with
    * 'connection_or_flushed_some()' -> 'scheduler_channel_wants_writes()'.