Re: [tor-bugs] #27813 [Core Tor/Tor]: Tor 0.3.4.8 is leaking memory

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#27813: Tor 0.3.4.8 is leaking memory
-------------------------------------------------+-------------------------
 Reporter:  anong                                |          Owner:  (none)
     Type:  defect                               |         Status:
                                                 |  needs_information
 Priority:  Very High                            |      Milestone:  Tor:
                                                 |  0.3.5.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.4.8
 Severity:  Critical                             |     Resolution:
 Keywords:  regression? memleak oom              |  Actual Points:
  034-backport tor-relay 035-must                |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by dgoulet):

 Replying to [comment:29 starlight]:
 > Reading this ticket and #28089 a potential concern comes to mind.  In my
 experience the Linux kernel is fastidious in releasing skb memory when
 sockets close, which leads to the question: is an additional bug present
 in KIST where sockets are leaked?  For kernel memory consumption to grow
 unbounded while the relay daemon continues to function correctly, a socket
 leak or stranding would appear necessary.  I do not know this code and
 someone familiar with it would be in a better position to consider the
 possibility.

 KIST doesn't manage sockets. It is a scheduler that only relays cell based
 on kernel information per-socket and trying to be fair by considering all
 circuits.

 The issue here is clearly the fact that one side of the connection (relay
 to relay) wasn't reading on the socket which caused the TCP window to
 shrink down to 0 and thus the other side queuing cells in the Kernel. That
 explains why nobody sees the memory leak in userspace by looking at tor's
 memory.

 KIST should prevent that in theory but not entirely. Some could always go
 as in flushing 1M of cells and only one goes through leaving the rest in
 the kernel.

 The bigger issue is that we still have cells bypassing the KIST scheduler
 that are directly written on the socket. We have several ticket open about
 these issues.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27813#comment:30>
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