[tor-bugs] #5263 [Tor Relay]: Busy/infinite Libevent loops

[Tor Bug Tracker & Wiki]

#5263: Busy/infinite Libevent loops
------------------------+---------------------------------------------------
 Reporter:  robgjansen  |          Owner:                    
     Type:  defect      |         Status:  needs_review      
 Priority:  major       |      Milestone:  Tor: 0.2.2.x-final
Component:  Tor Relay   |        Version:                    
 Keywords:              |         Parent:                    
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by nickm):

 Replying to [comment:4 robgjansen]:
 > > >The reason that both read and write events are both de-registered
 when the marked connection can not flush is because both result in the
 same behavior. Both read/write events on marked connections will never
 again do any actual reads/writes, and are only useful to trigger the flush
 and close the connection.
 > >
 > > I think I agree with this patch except for this question.  Is it
 really the case that we reach this point with the connection still
 reading?  Keep in mind that this case can only happen if the connection is
 marked and is busy flushing; a connection in that condition *shouldn't* be
 reading.   Did you run into some that were? If I missed something, though:
 sz==0 in that case doesn't mean that read is blocked on bandwidth; no read
 was attempted in the code above, and the read bucket wasn't examined.
 > >
 > > Can you tell me more about the read case here?
 >
 > I did run into a case where a connection was reading.
 >
 > You are technically correct about sz==0 not implying read is blocked on
 bandwidth. The reason I added that was to catch reading connections that
 are flushing but not registered as writing, because we need a way for the
 event to later get activated, flushed, and removed. Would it be better to
 remove the read event and set write_blocked_on_bandwidth to get ensure
 removal later?

 If the connection is marked, it really shouldn't be reading at all.  I'd
 be curious what kind of connections these are, and what made them read.
 Disabling 'read' if it's on is okay, I think.  And if we tried to write
 but we can't because of bandwidth, then write_blocked_on_bandwidth_ does
 sound appropriate.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5263#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online