Re: don't let mmap allocate down to zero

[Andy Isaacson <adi@hexapodia.org>]

On Wed, Jan 26, 2005 at 11:38:15AM -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Rik van Riel wrote:
> >With some programs the 2.6 kernel can end up allocating memory
> >at address zero, for a non-MAP_FIXED mmap call!  This causes
> >problems with some programs and is generally rude to do. This
> >simple patch fixes the problem in my tests.
> 
> Does this mean that we can't mmap the screen regen buffer at
> 0x000b8000 anymore?

That would be a MAP_FIXED call, so not affected by this change.

> How do I look at the real-mode interrupt table starting at
> offset 0? You know that the return value of mmap is to be
> checked for MAP_FAILED, not for NULL, don't you?

All MAP_FIXED, too.

> What 'C' standard do you refer to? Seg-faults on null pointers
> have nothing to do with the 'C' standard and everything to
> do with the platform.

Obviously having malloc() return NULL for a successful allocation would
be a bad thing, no?  That's precisely what could happen if an anonymous
allocation got mapped at 0x0.

> >+#define SHLIB_BASE             0x00111000

Any particular thoughts as to how large a window should be reserved?
SHLIB_BASE is a bit more than 1MB, which is fairly small in the grand
scheme of things, but I guess I don't see why you'd reserve more than
PAGE_SIZE (or maybe PAGE_SIZE*2, though I can't actually articulate why
that seems like a good idea).

FWIW, mmap(2) also will return NULL if length==0.  That sure did confuse
me the first time I noticed.

-andy