Date: Tue, 17 Aug 1999 11:11:30 +0400 From: Vadim Kolontsov <vadim@tversu.ru> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Mike Tancsa <mike@sentex.net>, freebsd-security@FreeBSD.ORG Subject: Re: Any work around for this FreeBSD bug/DoS ? Message-ID: <19990817111130.A8127@tversu.ru> In-Reply-To: <199908170527.WAA13380@apollo.backplane.com>; from Matthew Dillon on Mon, Aug 16, 1999 at 10:27:09PM -0700 References: <4.1.19990816203409.05989960@granite.sentex.ca> <4.1.19990816213403.05a3b540@granite.sentex.ca> <199908170527.WAA13380@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 16, 1999 at 10:27:09PM -0700, Matthew Dillon wrote: > > So, for example, if you limit normal users to 30 processes and 40 > file descriptors per process you wind up with a maximum of 1200 open > descriptors. If you limit the socket buffer to 16384, that's 32K > per descriptor and around 38MB of ram. The system would have to be > configured with a sufficient number of network mbufs such that a single > user allocating 38MB of ram does not run the system out. I've read that "once memory is allocated for mbufs clusters, it is never freed". So after user program exits/dies, 38MB list of free mbufs remains; will it have any [network code] perfomance consequences? will those mbufs just be paged out? sorry if the question doesn't make sense :) V. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990817111130.A8127>