Date: Tue, 28 Dec 1999 13:00:58 -0500 (EST) From: Bosko Milekic <bmilekic@dsuper.net> To: Tom <tom@uniserve.com> Cc: Mike Smith <msmith@FreeBSD.ORG>, "Mr. K." <bsd@inbox.org>, stable@FreeBSD.ORG Subject: Re: panic Message-ID: <Pine.OSF.4.05.9912281241100.23276-100000@oracle.dsuper.net> In-Reply-To: <Pine.BSF.4.02A.9912280925410.9441-100000@shell.uniserve.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Dec 1999, Tom wrote: !>> The semantics of "should" and "shouldn't" are debatable. In this case, !>> the panic is a simple indicator that the administrator hasn't correctly !>> tuned the system. Many would argue that this is a much better outcome !>> than a system that performs poorly for no immediately perceptible reason, !>> and it certainly encourages the prompt application of a correct !>> adjustment. !> !> Well, in FreeBSD 2.2.x, an "Out of mbufs!" message was printed on the !>console, and there was no panic. Right, and then do you know what happen? Most likely, you would page fault "somewhere" else in the code, because of that calling code would again not end up being able to handle the NULL pointer or, worse yet, not even check for it. Personally, I don't believe that "solving" the problem originally by inserting an explicit panic() on failure was a good solution. In fact, it basically transported the problem over to the mbuf code, which can't predict the context of the caller, in the sense that it's difficult to decide *how* to fail when it has to. Thus, the "wait" code was written to modify the behavior of the code in the event that a shortage occurs. This, as I mentionned in my previous post, does _not_ excuse any of the calling code from properly checking for failure. You'll find many such kludges around the NFS code, for example. What's important to understand is that allocation of an mbuf even with M_WAIT does *not* guarantee success because if we're short, it's frankly rather useless to wait forever. With that said, since you're running -STABLE as opposed to -CURRENT, the wait code, nor the ulimit on sockbuf space code for that matter, have been MFCed at this time. "To MFC or not to MFC" is not a decision that I am to make, since I don't represent the project `officially.' Therefore, you can either merge them over yourself (it's not that difficult) -- that is, if you're somewhat familiar with the code -- or wait and tune your system while waiting accordingly. If whoever would like to offer further complaints about something not being the way it should, I have to mention again that "whoever" should equally provide detailed information on the crash, which in this case has not yet been done; therefore, all that I've mentionned above is assuming of course that the crash is the _direct_ result of the explicit panic() in m_retry. Bosko. ...... . . . . . . . . . . . . . Bosko Milekic -- bmilekic@dsuper.net . . . . . . . . . . . ...... . . WWW: http://pages.infinit.net/bmilekic/ . ................................................ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.05.9912281241100.23276-100000>