From owner-freebsd-hackers Fri Sep 17 16:17:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id 1880115B68; Fri, 17 Sep 1999 16:16:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id QAA04542; Fri, 17 Sep 1999 16:12:46 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA20252; Sun, 12 Sep 1999 20:36:59 -0700 (PDT) (envelope-from dillon) Date: Sun, 12 Sep 1999 20:36:59 -0700 (PDT) From: Matthew Dillon Message-Id: <199909130336.UAA20252@apollo.backplane.com> To: Bosko Milekic Cc: Stas Kisel , avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think that what needs to be done is to split the problem in two. First, allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT is used, it simply means 'try harder, sleeping a bit if necessary'. This requires ensuring that all the networking code deal with the failure case - a time consuming but straightforward task. If a failure occurs, one simply drops the packet, not the connection or anything else drastic. just the packet. The second problem that needs to be addressed is resource exhaustion. For example, allocating thousands of connections and socket-opting their buffers as large as possible, or programs such as syslog accepting new connections ad-infinitum. This is a harder problem to fix properly, but a lot of the various issues such as those with syslog can be dealt with in userland rather then the kernel. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message