|
From: Jeff D. <jd...@ka...> - 2002-12-28 05:33:20
|
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. Jeff |
|
From: Jeff D. <jd...@ka...> - 2002-12-28 05:37:49
|
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. ... 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. Jeff |
|
From: Jeremy F. <je...@go...> - 2002-12-28 07:20:56
|
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 |