Date: Mon, 7 May 2001 11:44:48 -0700 (PDT) From: Dennis Glatting <dennis.glatting@software-munitions.com> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Kris Kennaway <kris@obsecurity.org>, <freebsd-stable@frebsd.org>, <freebsd-current@FreeBSD.ORG> Subject: Re: pgm to kill 4.3 via vm Message-ID: <20010507112937.V47835-100000@btw.plaintalk.bellevue.wa.us> In-Reply-To: <xzpu22xm9ow.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 May 2001, Dag-Erling Smorgrav wrote: > Dennis Glatting <dennis.glatting@software-munitions.com> writes: > > On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote: > > > malloc() will return NULL only if you hit a resource limit or exhaust > > > address space. There may or may not be memory (real or virtual) > > > available at that time. > > Isn't memory exhaustion a resource limit? > > What is memory exhaustion? > Uh, when I perform a malloc() and get a NULL back? I dunno, what do you call that? > Namespace exhaustion will cause malloc() to fail. But FreeBSD > overcommits memory, so exhaustion of physical and virtual memory will > manifest itself as an unsatisfiable page fault, which will cause the > kernel to start killing more-or-less-random processes until some > memory is available again. > Why would it kill random processes as opposed to the offending process? > > Explain the bug and malloc() behaviour. According to the malloc() man > > page: > > The bug: I believe you meant "i -= j" when you wrote "i =- j". The > result is that i becomes negative and in all likelihood you smash the > malloc() arena. > Yup. > Regarding malloc(), you seem to believe that malloc() allocates > *exactly* the amount you ask, no more, no less, and actually allocates > physical or virtual memory. It doesn't. First of all, it allocates > memory of its own for bookkeeping purposes, which your program doesn't > account for. Second, it usually allocates a little bit more than you > asked for, and keeps the leftovers for later. Third, it only > allocates namespace. Actual memory (physical or virtual) is allocated > by the kernel the first time you touch a page. > I am not under the impression malloc allocs an exact space. > What's more, your program does extra stuff (such as needlessly fork() > / exec()ing sync(1) instead of just calling sync(2), which doesn't > serve any purpose anyway, since virtual memory isn't managed by the > file system code, so sync(2) doesn't affect it) which consumes memory, > which further invalidates your results (for instance, memory > exhaustion while running sync(1) could cause the kernel to randomly > kill your program) > Regardless, the code shouldn't be crashing the kernel. > > I assert memory exhaustion is would return "unsuccessful" on the > > malloc() call, no? > > No, just namespace exhaustion, which your program won't even come > close to. > I don't really understand your point. Who really cares whether it is a name space exhaustion or an exhaustion of virual memory or a fly sat on the keyboard: malloc() was called and the kernel crashed. The kernel should have failed the offending system call or killed the offending application. In the real world there are plenty of reasons why an operating system may run at or near its limits (whatever a limit may be). Example anomolies include: * a web server hit by a DoS, * a database server hit with a flurry of processing tasks * someone sending spam through your mail server Is it reasonable to kill the operating system when these things happen? No. The kernel should always be better behaved than the application. > DES > -- > Dag-Erling Smorgrav - des@ofug.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010507112937.V47835-100000>