Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!ames!ncar!husc6!ddl
From: ddl@husc6.harvard.edu (Dan Lanciani)
Newsgroups: comp.bugs.2bsd
Subject: Re: TIME_WAIT sockets clog system (part 2)
Keywords: ftp mbufs time_wait drain
Message-ID: <2149@husc6.harvard.edu>
Date: 2 Jul 89 01:08:34 GMT
References: <33132@wlbr.IMSD.CONTEL.COM> <2144@husc6.harvard.edu> <33315@wlbr.IMSD.CONTEL.COM>
Organization: Harvard University, Cambridge MA
Lines: 58

In article <33315@wlbr.IMSD.CONTEL.COM>, sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz(Y)) writes:
| 	Inadvertent lowering of the priority is the bugaboo to be
| 	afraid of as i understand it, the consequences of recursive
| 	interrupts, etc are well known to me (i only blew it twice in
| 	getting if_ec.c working for 2.10.1BSD).

	This is no more or less to be feared than corruption of global
data structures.

| 	The m_more() routine is required to be called at splimp(), not splnet().
| 
| 	The m_expand() routine which is called by m_more() also is required 
| 	to be called at splimp().

	This is done so that the allocator can be called from plimp
interrupt routines.  The mbuf allocator is one of the few pieces of
the network that may be called by such routines.  Another is the
arpinput code, but that's easy to get rid of and I digress...

| 	The tcp_drain() routine i proposed (actually i'm running it as i type)
| 	raises spl to splimp() out of paranoia.  Besides which, the *_drain 
| 	routines are only called from m_expand() which is at splimp already.

	This piece of paranoia both does no good and is misleading.  It
protects your tcp_drain routine from being interrupted, but this isn't
the problem.  The problem is that your tcp_drain routine can be *called*
from a plimp interrupt routine.  In any case, the problem is not
with tcp_drain, but with the modification to the memory allocator.

| 	Last i looked, splimp() is higher than splnet() so there is not
| 	any inadvertent lowering of priority.

	But your tcp_drain does not stand by itself.  It calls tcp_close.
Tcp_close calls (among other things) in_pcbdetach.  In_pcbdetach access
the linked list of protocol control blocks.  It also calls sofree.

| 	Yes, if in the future, the *_drain routines get "smarter" or more
| 	complicated, then problems probably will arise.  Given the current
| 	setup everything seems in order.

	You can't get much more complicated than calling the tcp_close
function...

| 	What have i missed?  Please be kind - it was late when i "had to
| 	do something about the ftp mget" problem ;-)

	From the structure of your loop in tcp_drain, you obviously
noticed that tcp_close will delete protocol control blocks from the
tcb chain.  How would you feel if you were a happy little plnet
routine walking the tcb chain and then the tcp_drain routine was called
by the ethernet interrupt's asking for an mbuf, thus invalidating
your pointer?
	For a more definite example, consider the tcp_fasttimo routine
and think about what would happen if you deleted the protocol control
block that it was currently looking at.

				Dan Lanciani
				ddl@harvard.*