From owner-freebsd-current Sat May 8 9:32:18 1999 Delivered-To: freebsd-current@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id EFBCD152BF for ; Sat, 8 May 1999 09:32:14 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id LAA25632; Sat, 8 May 1999 11:53:44 -0500 (EST) Date: Sat, 8 May 1999 11:53:43 -0500 (EST) From: Alfred Perlstein To: Luigi Rizzo Cc: current@FreeBSD.ORG Subject: Re: m_get(M_WAIT, ...) _can_ return NULL ? In-Reply-To: <199905081332.PAA07452@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 8 May 1999, Luigi Rizzo wrote: > Hi, > > thinking about the supposed "fragility" of FreeBSD when mbufs (or > clusters) are not properly dimensioned: i notice that > in various places of the code (and this is, i think, 4.4 heritage), > there are things like > > m = m_get(M_WAIT, ...) > m->m_len = something. > > looking at the code, it seems that m_get() _can_ return a NULL pointer > even if one specifies M_WAIT. > > Could this be a potential weakness, and in this case, how shuld we go > and fix it -- by making m_get never return if there is no memory, > or by hunting all such occurrences of the code ? I'm pretty sure there was a discussion about this almost a year ago, the situation with m_get+M_WAIT possibly returning NULL got so man people annoyed that a few sent in patches that REALLY helped FreeBSD remain stable during severe mbuf shortages. Unfortunatly it seems that they didn't catch every place. I think the answer is to figure out how to make these places "back out" instead of making m_get totally blocking, It gives more control. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message