Content-Type: text/plain; charset=US-ASCII
From: Jesse Pollard <jesse@cats-chateau.net>
To: Timothy Miller <miller@techsource.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: top stack (l)users for 2.5.69
Date: Wed, 7 May 2003 17:01:11 -0500
References: <20030507132024.GB18177@wohnheim.fh-wedel.de> <03050716305002.07468@tabby> <3EB980AA.9060207@techsource.com>
In-Reply-To: <3EB980AA.9060207@techsource.com>
MIME-Version: 1.0
Message-Id: <03050717011103.07468@tabby>
Content-Transfer-Encoding: 7BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1342
Lines: 29

On Wednesday 07 May 2003 16:54, Timothy Miller wrote:
> Jesse Pollard wrote:
> > On Wednesday 07 May 2003 12:13, Jonathan Lundell wrote:
> > [snip]
> >
> >>One thing that would help (aside from separate interrupt stacks)
> >>would be a guard page below the stack. That wouldn't require any
> >>physical memory to be reserved, and would provide positive indication
> >>of stack overflow without significant runtime overhead.
> >
> > It does take up a page table entry, which may also be in short supply
>
> Now, I'm sure this has GOT to be a terribly ignorant question, but I'll
> try anyhow:
>
> What happens if you simply neglect to provide a mapping for that page?
> I'm sure that will cause some sort of page fault.  Why would you have to
> do something different?

I believe it shifts the entire virtual range up(/down depending on your point
of view). Each page in the virtual address range (whether it physically
exists or not) has a descriptor. To reserve one requires that the descriptor
be set to "does not exist, no read, no write". Then any access to that page
can/will generate a trap.
-
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/