From owner-freebsd-net Fri Dec 21 10:41:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable099.144-201-24.mtl.mc.videotron.ca [24.201.144.99]) by hub.freebsd.org (Postfix) with ESMTP id 33FE337B419 for ; Fri, 21 Dec 2001 10:41:34 -0800 (PST) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id fBLIh7w69266; Fri, 21 Dec 2001 13:43:07 -0500 (EST) (envelope-from bmilekic) Date: Fri, 21 Dec 2001 13:43:07 -0500 From: Bosko Milekic To: Randall Stewart Cc: net@FreeBSD.ORG Subject: Re: m_reclaim and a protocol drain Message-ID: <20011221134307.A69233@technokratis.com> References: <3C235866.B063CC7B@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C235866.B063CC7B@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Fri, Dec 21, 2001 at 09:42:30AM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Dec 21, 2001 at 09:42:30AM -0600, Randall Stewart wrote: > Hi all: > > I have a question. I have been working to test the new > sctp_drain function I am adding and have had a very difficult > time getting the drain function to be called by the mbuf system... > > Now here is what I most observe from some of the test cases > I am building: > > A) All inbound packets get a cluster down in the driver routine. > B) There is a much smaller limit to clusters > C) The cluster allocation routine will NOT call reclaim() et.al. This has changed in -CURRENT and it should be easy to change -STABLE to do the same. -CURRENT now drains the protocols in the cluster starvation case too. > D) Of course since the lower drivers are allocating M_DONTWAIT > even if they did I would not get the routine called. > > Now this brings to light a weakness in my mind on the reclaim > system. > > 1) One of the primary things I thought the drain() functions > help with is to ward off DOS attacks. Well, no, not really. They're just there to `help' out in any starvation case, really. > 2) If drivers all use clusters only and clusters can never > call a drain() function, does this not leave both TCP and > SCTP weak against an attack on the cluster side of the MBUF > system? Well, firstly, all clusters are accompanied by mbufs. Secondly, as mentionned above, -CURRENT drains in both cases. > 3) I can see if we are out of mbufs eventually something sending > down will do a mget(..) with a M_WAIT which can spawn the drains > should we not have something like this for a cluster allocation?? There's no way we can have M_DONTWAIT allocations possibly drain the protocols. It would be way too much time for an M_DONTWAIT allocation, especially in light of where we may be going with this in the future (i.e. processing some packets from interrupt context - perhaps). What I think you should do in your code is make the calls with M_TRYWAIT (what you call M_WAIT) wherever they are possible and only call with M_DONTWAIT where it's really not possible to wait. The M_TRYWAIT flag does not imply "run slower than M_DONTWAIT," it just means "try harder even if it takes a little longer, since we are able to block." > If we don't it seems to me the utility of the drain() fucnction is > very very limited.. > > Regards > > R > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) -- Bosko Milekic bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message