[Valgrind-developers] Re: Stack switches vs stack growth/shrinkage

[Jeremy F. <je...@go...>]

On Fri, 2002-12-27 at 21:36, Jeff Dike wrote:
> je...@go... said:
> > It seems to me that the correct check to apply is to see if there are
> > already some valid/invalid addresses in that range; if so, this is a
> > stack switch; if not, it is a stack extension/contraction.  
> 
> What happens if the memory in between is free?  In the kernel, if the pages
> in between the two stacks are free, then I have them marked as no-access,
> and this would seem to trigger your stack expansion logic.

So you mean the initial switch to a new stack from the stack which is
immediately above it in memory?  I don't think that will be a problem. 
Assuming you're talking about some kind of threading system, I think the
creator of a thread will always allocate the memory for the new thread
before starting it, which means that the bottom of the stack (uppermost
addresses) will be made valid before the attempt to point %esp at it.  

After all, as Julian discovered, if you simply start accessing the new
stack without any other preparation, and you have no stack size limit,
the kernel will interpret that as a stack extension too.

> ... and 5 seconds after posting my devastating critique of this plan,
> I think of something which saves it ...
> 
> And that is that there is always something at the bottom of a kernel
> stack (a task_struct in 2.4, a thread_info in 2.5).  This will be
> marked valid, a stack switch will always jump over one, a stack
> expansion never will, so at least in the kernel, this is a safe
> heuristic.

I actually think its always safe; I can't think of a reasonable usage
which wouldn't trigger the test on a stack switch, for precisely this
reason.  Even if the threads system doesn't initialize the new thread
stack with any data, the memory will have been at least allocated by the
time of the first context switch to that thread.

	J