[tor-commits] [tor/release-0.3.2] sched: Set channel scheduler state to IDLE when not opened

nickm at torproject.org nickm at torproject.org
Wed Dec 6 19:38:11 UTC 2017


commit 97702c69b03b19a8a6f867e56f716ce984550fa0
Author: David Goulet <dgoulet at torproject.org>
Date:   Mon Dec 4 14:48:15 2017 -0500

    sched: Set channel scheduler state to IDLE when not opened
    
    In the KIST main loop, if the channel happens to be not opened, set its state
    to IDLE so we can release it properly later on. Prior to this fix, the channel
    was in PENDING state, removed from the channel pending list and then kept in
    that state because it is not opened.
    
    This bug was introduced in commit dcabf801e52a83e2c3cc23ccc1fa906582a927d6 for
    which we made the scheduler loop not consider unopened channel.
    
    This has no consequences on tor except for an annoying but harmless BUG()
    warning.
    
    Fixes #24502
    
    Signed-off-by: David Goulet <dgoulet at torproject.org>
---
 changes/bug24502        | 4 ++++
 src/or/scheduler_kist.c | 5 ++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/changes/bug24502 b/changes/bug24502
new file mode 100644
index 000000000..3fa6fb58d
--- /dev/null
+++ b/changes/bug24502
@@ -0,0 +1,4 @@
+  o Minor bugfixes (scheduler):
+    - Properly set the scheduler state of an unopened channel in the KIST
+      scheduler main loop. This prevents a harmless but annoying log warning.
+      Fixes bug 24502; bugfix on 0.3.2.4-alpha.
diff --git a/src/or/scheduler_kist.c b/src/or/scheduler_kist.c
index fea92705d..3d8f553ac 100644
--- a/src/or/scheduler_kist.c
+++ b/src/or/scheduler_kist.c
@@ -606,9 +606,12 @@ kist_scheduler_run(void)
        * 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
+       * error at this point. So before we continue, make sure the channel is
        * open and if not just ignore it. See #23751. */
       if (!CHANNEL_IS_OPEN(chan)) {
+        /* Channel isn't open so we put it back in IDLE mode. It is either
+         * renegotiating its TLS session or about to be released. */
+        chan->scheduler_state = SCHED_CHAN_IDLE;
         continue;
       }
       /* flush_result has the # cells flushed */





More information about the tor-commits mailing list