[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #21302 [Core Tor/Tor]: hs: Multiple service issues
#21302: hs: Multiple service issues
--------------------------+------------------------------------
Reporter: dgoulet | Owner: dgoulet
Type: defect | Status: needs_review
Priority: Medium | Milestone: Tor: 0.3.0.x-final
Component: Core Tor/Tor | Version: Tor: 0.2.9.8
Severity: Normal | Resolution:
Keywords: tor-hs | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------+------------------------------------
Comment (by dgoulet):
Replying to [comment:3 nickm]:
> In a82e572e9ff5994d2ba14dcc1a25995f6bdda9b7, how do we know that
count_intro_point_circuits() is always greater than expiring_nodes_len?
In other words, how can we be sure that this subtraction never underflows:
> {{{
> + num_ip_circuits = count_intro_point_circuits(service) -
expiring_nodes_len;
> }}}
Great observation. In *theory*, if a node is in the expiring node list it
means it has a circuit. This is why the third commit actually improves on
that and could be a cause of the unsolved #21297. However, I don't believe
we have a good guarantee of this. Real guarantee would be that when we
close an HS circuits, we also make sure anything expecting a circuit is
cleaned up.
How is this fixup commit looking? `c1f6238c`.
>
> The other commits look okay to me, if you've tested them. (We've
actually removed something with the loop in
0342c1a82c56ad1f9ae9b8a536f32355640dc4bd, yeah?)
Yes it has been tested. Would be nice to have asn's eyes on that as well.
It is quite core in the HS subsystem but worth fixing!
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21302#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs