Date: Wed, 26 Dec 2001 06:13:40 -0600 From: Randall Stewart <randall@stewart.chicago.il.us> To: Bosko Milekic <bmilekic@technokratis.com> Cc: net@FreeBSD.ORG Subject: Re: m_reclaim and a protocol drain Message-ID: <3C29BEF3.611BCAFE@stewart.chicago.il.us> References: <3C235866.B063CC7B@stewart.chicago.il.us> <20011221134307.A69233@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko: Sorry for the delayed response... some comments below.. Bosko Milekic wrote: > > 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. > This comment facinates me. The reason we made SACK's in SCTP revokeable is due to the potential DOS attack that someone can supposedly lauch if you don't allow the stack to revoke. I can actually see the reason that Sally made the comments and had us change it so that SACK's are revokeable. However you argue to the contrary and I wonder which is correct. If you do not allow revoking it is the same as if a protocol does not hold a drain() fucntion. A attacker could easily stuff a lot of out-of-order segments at you and thus fill up all your mbuf's or clusters (in my current testing case). This would then yeild a DOS since you could no longer receive any segments and leave you high and dry.... > > 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. > Hmm.. I will look at updating this... > > 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." > A couple of comments here: a) There is NO M_TRYWAIT in the 4.3 strain I am working on.. I am about to upgrade to 4.4. so maybe it will appear there :> b) It is NOT my code that I am talking about. The issue is I am stuffing a LOT of out-of-order segments up the SCTP stack to get the drain() function called (so I can test it). Nothing ever calls the drain function and instead we lose packets at input since the drivers in the ethernet side of things (as you mention) do a M_DONTWAIT. My code uses M_WAIT wherever it can... Hmm, maybe thats it... I need to somehow activate a condition where I send a large segment and do a M_WAIT... Probably easier to build a test ioctl to call the drain function though.. R > > 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 -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) 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?3C29BEF3.611BCAFE>