Date: Wed, 26 Jan 2005 15:42:35 -0500 (EST)
From: Rik van Riel <riel@redhat.com>
To: Andy Isaacson <adi@hexapodia.org>
cc: linux-os <linux-os@analogic.com>, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org, James Antill <james.antill@redhat.com>,
       Bryn Reeves <breeves@redhat.com>
Subject: Re: don't let mmap allocate down to zero
In-Reply-To: <20050126202639.GA10106@hexapodia.org>
Message-ID: <Pine.LNX.4.61.0501261541020.5677@chimarrao.boston.redhat.com>
References: <Pine.LNX.4.61.0501261116140.5677@chimarrao.boston.redhat.com>
 <Pine.LNX.4.61.0501261130130.17993@chaos.analogic.com> <20050126202639.GA10106@hexapodia.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1141
Lines: 25

On Wed, 26 Jan 2005, Andy Isaacson wrote:

> 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).

You also want to catch not-quite-NULL pointer dereferences,
where you dereference the member of a large struct or array,
but the array or struct pointer itself was NULL.

Eg. you try to fetch the 100,000th from an array, but you
got passed a NULL array pointer.  Getting a segfault is
much, much better than corrupting data.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/