Date: Sat, 13 May 2000 01:43:11 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: Mike Silbersack <silby@silby.com> Cc: net@FreeBSD.ORG Subject: Re: MFC of mbuf wait and other patch Message-ID: <Pine.BSF.4.21.0005130118180.14833-100000@jehovah.technokratis.com> In-Reply-To: <Pine.BSF.4.21.0005121927480.1239-100000@achilles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 May 2000, Mike Silbersack wrote: > The first is a patch I posted a week or two ago here which rate limits > icmp echo responses and timestamp responses; while it doesn't address any > particular DoS, I think it'd be wise to include, even if only in current > for now. > > You can obtain it from: http://www.silby.com/patches/ip_icmp.c.patch Looks good to me. > > The second patch is my backport of bosko milekic's mbuf waiting code to > 3.4. The patch ported cleanly, but I'm seeing mbuf leaks in some cases > when I reach the exhaustion stage. Unfortunately, since I only have a 3.4 > box, I cannot tell if this is due to an error in my backport, or some case > that isn't handled by the code. If you're running 4 or 5 and wish to see > the results you get from the attack I'm running on myself, please e-mail > me and I'll send you instructions on how to recreate it. If you want, what you could do is also backport some of the changes to netstat (along with the addition of the kern.ipc.nmbufs sysctl node), as I've noticed that you also merged the bits that place hard limits on allocate-able mbufs and mclusters. As for the "leak," as previously mentionned, it would be helpful to know the state of some processes. In particular, you want to look for process(es) with WCHAN "mballc" or "mclalc" (particularily the ones that seem to be "hanging" on you during the exhaustion). As we've discussed, such processes are typically stuck in the kernel, trying to substitute clusters with mbufs, while continuously timing out on the tsleep()s in the mcluster allocation routine. Unfortunately, such system calls don't return until they decide that they have exhausted all mbufs, too... which means they'll be at it for a while because you usually run out of clusters sooner that you do of mbufs. In any case, carefully look at mbuf and mcluster variations, stop the "attack/DoS/whatever" simulation, and change the timeout on the sleeps. Then try again. Also, keep an eye out on those processes. > > That aside, the patch does stop the box from panicing, so it's still a win > for us 3.xers - if you're running 3.4, please help test the patch. > > The mbuf wait patch is at: > http://www.silby.com/patches/mbuf-wait-mfc.patch The patch looks fine, except for some mbuf.h-related stuff which would probably benefit from a quick review by Brian (green@freebsd.org), as he's done (much needed) cleanups there not too long ago. > > Thanks, > > Mike "Silby" Silbersack > Later, Bosko. -- Bosko Milekic * pages.infinit.net/bmilekic/index.html * www.technokratis.com bmilekic@dsuper.net * bmilekic@technokratis.com * b.milekic@marianopolis.edu "Give a man a fish and he will eat for a day. Teach him how to fish, and he will sit in a boat and drink beer all day." 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?Pine.BSF.4.21.0005130118180.14833-100000>