[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [tor] branch main updated: Properly compute cell-drop overload fraction



This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main
in repository tor.

The following commit(s) were added to refs/heads/main by this push:
     new d09414858e Properly compute cell-drop overload fraction
     new 4692cf8688 Merge branch 'maint-0.4.7'
d09414858e is described below

commit d09414858e2f5c5efa2ece4b3a32a6b47374dfdd
Author: Andy <andy@xxxxxxxxxxxxxxxxx>
AuthorDate: Thu Oct 6 04:30:18 2022 +0000

    Properly compute cell-drop overload fraction
    
    Patch to address #40673. An additional check has been added to
    onion_pending_add() in order to ensure that we avoid counting create
    cells from clients.
    
    In the cpuworker.c assign_onionskin_to_cpuworker
    method if total_pending_tasks >= max_pending_tasks
    and channel_is_client(circ->p_chan) returns false then
    rep_hist_note_circuit_handshake_dropped() will be called and
    rep_hist_note_circuit_handshake_assigned() will not be called. This
    causes relays to run into errors due to the fact that the number of
    dropped packets exceeds the total number of assigned packets.
    
    To avoid this situation a check has been added to
    onion_pending_add() to ensure that these erroneous calls to
    rep_hist_note_circuit_handshake_dropped() are not made.
    
    See the #40673 ticket for the conversation with armadev about this issue.
---
 changes/bug40673                | 7 +++++++
 src/feature/relay/onion_queue.c | 7 ++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/changes/bug40673 b/changes/bug40673
new file mode 100644
index 0000000000..16763ed258
--- /dev/null
+++ b/changes/bug40673
@@ -0,0 +1,7 @@
+  o Minor bugfixes (relay overload statistics):
+    - Count total create cells vs dropped rate cells properly, when
+      assessing if our fraction of dropped cells is too high. We only
+      count non-client circuits in the denominator, but we would include
+      client circuits in the numerator, leading to surprising log lines
+      claiming that we had dropped more than 100% of incoming create
+      cells. Fixes bug 40673; bugfix on 0.4.7.1-alpha.
diff --git a/src/feature/relay/onion_queue.c b/src/feature/relay/onion_queue.c
index 81a655135d..c4d55dc510 100644
--- a/src/feature/relay/onion_queue.c
+++ b/src/feature/relay/onion_queue.c
@@ -36,6 +36,7 @@
 #include "feature/stats/rephist.h"
 
 #include "core/or/or_circuit_st.h"
+#include "core/or/channel.h"
 
 /** Type for a linked list of circuits that are waiting for a free CPU worker
  * to process a waiting onion handshake. */
@@ -188,7 +189,11 @@ onion_pending_add(or_circuit_t *circ, create_cell_t *onionskin)
 #define WARN_TOO_MANY_CIRC_CREATIONS_INTERVAL (60)
     static ratelim_t last_warned =
       RATELIM_INIT(WARN_TOO_MANY_CIRC_CREATIONS_INTERVAL);
-    rep_hist_note_circuit_handshake_dropped(queue_idx);
+    if (!channel_is_client(circ->p_chan)) {
+      // Avoid counting create cells from clients, to go with the same
+      // check in command_process_create_cell().
+      rep_hist_note_circuit_handshake_dropped(queue_idx);
+    }
     if (queue_idx == ONION_HANDSHAKE_TYPE_NTOR) {
       char *m;
       if ((m = rate_limit_log(&last_warned, approx_time()))) {

-- 
To stop receiving notification emails like this one, please contact
the administrator of this repository.
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits