Date: Fri, 21 Dec 2001 13:43:07 -0500 From: Bosko Milekic <bmilekic@technokratis.com> To: Randall Stewart <randall@stewart.chicago.il.us> Cc: net@FreeBSD.ORG Subject: Re: m_reclaim and a protocol drain Message-ID: <20011221134307.A69233@technokratis.com> 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 References: <3C235866.B063CC7B@stewart.chicago.il.us>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011221134307.A69233>