Date: Mon, 01 Sep 2003 14:02:39 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Pawel Jakub Dawidek <nick@garage.freebsd.pl> Cc: current@FreeBSD.org Subject: Re: need some debugging help Message-ID: <3F53B3EF.2DC9F755@mindspring.com> References: <20030831070854.GA54748@panzer.kdm.org> <20030901064840.GA61253@panzer.kdm.org> <20030901103016.GI47959@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek wrote: > On Mon, Sep 01, 2003 at 12:48:41AM -0600, Kenneth D. Merry wrote: > +> - I tried just holding a mutex all the time, but obviously you can't > +> malloc while holding a mutex (except Giant), and the sysctl code does a > +> number of mallocs. (The original cause of this problem -- M_WAITOK > +> mallocs.) > > I've proposed some time ago changing M_WAITOK to M_NOWAIT, because > function/macros responsible for sysctl creation could failed from other > reasons, so I don't see any reason why they couldn't fail because of > insufficient memory. Caller is obliged to check return value... M_WAITOK is obliged to wait for fricking ever if it can't allocate the memory, rather than failing and returning a NULL pointer that then gets dereferenced because the function returned when the code expected the traditional M_WAITOK semantics. In other words, this problem derives from a semantics change, not from any actual bug. If you don't like it, then you need to change every instance of a call to malloc with M_WAITOK to check its return value before using it. Doing this does'nt require introducing yet another semantic. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F53B3EF.2DC9F755>