Date: Sun, 25 Feb 2001 22:06:18 -0800 From: Julian Elischer <julian@elischer.org> To: Archie Cobbs <archie@dellroad.org> Cc: Warner Losh <imp@village.org>, Peter Seebach <seebs@plethora.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. Message-ID: <3A99F25A.B940BEE0@elischer.org> References: <200102260529.f1Q5T8413011@curve.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Archie Cobbs wrote: > > Warner Losh writes: > > : >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who > > : >*wants* that feature to sit down and code it. It won't happen otherwise. > > : > > : So, out of idle curiousity: If, somewhere down the road, I know the kernel > > : well enough to attempt such a thing, what would the interest level be in > > : merging such a feature? > > > > Assuming that it doesn't break anything, that it doesn't introduce a > > severe performance penalty and works, there would be interest. There > > are times that this is a desirable feature. > > This thread reminds me of what happened when I brought up the same > issue a few years ago, arguing that the kernel shouldn't overcommit > memory (i.e., the same thing, everybody though I was nuts :) > > For me it helps to understand people's underlying motivation. Here's > mine... my perspective probably comes from using FreeBSD in the > embedded world, which is very different from using FreeBSD in the > rack-mounted server world. > > One important way to gain confidence that you're little box won't > silently crash at the worst possible time for the customer is to > be able to *prove* to yourself that it can't happen, given certain > assumptions. Those assumptions usually include things like "the > hardware is working properly" (e.g., no ECC errors) and "the compiler > compiled my C code correctly". > > Given these basic assumptions, you go through and check that you've > properly handled every possible case of input (malicious or otherwise) > from the outside world. Part of the "proof" is verifying that you've > checked all of your malloc(3) return values for NULL.. and assuming > that if malloc(3) returns != NULL, then the memory is really there. > > Now, if malloc can return NULL and the memory *not* really be there, > there is simply no way to prove that your code is not going to crash. > > This memory overcommit thing is the only case that I can think of > where this happens, given the basic assumptions of correctly > functioning hardware, etc. That is why it's especially annoying to > (some) people. I still think that in such a case it should be possible to 'test the commitment' by touching all the allocated memory while trapping page faults. and fault all your memory from 'potential' to 'allocated'. As someone said. it is not sure which program when you run out of swap, but I think you might be able to somehow change this behaviour to "the program making the request" fails (or gets a fault). You could allocate your memory. trap faults. touch all of the allocated memory. if it faults, you can remap some file to that location to allow the instruction to continue.. continue and abort the check.. exit as needed, OR continue with secure knowledge that all your memory is there. Alternatively you could allocate your own on-disk swapspace for a program by telling malloc to use a file for all your memory needs. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A99F25A.B940BEE0>