Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!apple!voder!wlbr!WLV.IMSD.CONTEL.COM!sms
From: sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz(Y))
Newsgroups: comp.bugs.2bsd
Subject: Re: TIME_WAIT sockets clog system (part 2)
Keywords: ftp mbufs time_wait drain
Message-ID: <33315@wlbr.IMSD.CONTEL.COM>
Date: 30 Jun 89 23:30:16 GMT
References: <33132@wlbr.IMSD.CONTEL.COM> <2144@husc6.harvard.edu>
Sender: news@wlbr.IMSD.CONTEL.COM
Reply-To: sms@WLV.IMSD.CONTEL.COM.UUCP (Steven M. Schultz(Y))
Organization: Contel Federal Systems
Lines: 53

In article <2144@husc6.harvard.edu> ddl@husc6.harvard.edu (Dan Lanciani) writes:

>	There is a potential problem with the proposed modifications
>to the mbuf allocator.  The "cantwait" argument to the allocation
>routines is more than just an indication of whether it is ok to sleep.
>It is also a subtle hint that the routine was not called from a
>(potentially plimp) interrupt routine.  If an allocation routine
>is called from, e.g., the ethernet interrupt it would be incorrect
>to (re)enter the network at plnet because (1) the network code may
>inadvertently lower the pl and (2) the network code may itself have
>been interrupted at a critical section.

>	Unfortunately, to be useful, most *_drain routines must
>ultimately access global structures which are protected only by
>splnet's and thus are eventually likely to cause corruption.  

	Thanks for the hints/warning.

	i'd like to "explore"/"discuss" this a bit.

	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).

	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().

	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.

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

	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.

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

>The solution was to make allocation requests which
>*could* wait *always* wait until some fraction (say, 50%) of
>mbufs were free.  This is effect reserved half of the mbufs
>for code that couldn't wait and improved matters significantly.

	Hmmmm, that sounds interesting!  Might be worth a shot.  Thanks!

	Steven M. Schultz
	sms@wlv.imsd.contel.com