On Don, 2008-04-24 at 17:08 +0200, Michael Blizek wrote: > Hi! > > On 14:41 Thu 24 Apr , sahlot arvind wrote: > > Why do we have two stacks per process i.e. one user mode and other kernel > > mode? > > As soon as process enters into kernel mode it starts using kernel mode > > stack, but as soon as it comes out of kernel mode stack there is nothing in The problems are more ugly: - How much space is left in the page at the end at that point? - What, if another page is needed because only 10 bytes are left? - If there are more pages already mapped, they may be swapped out. If this is one page, one can swap it in (and schedule etc.). But what, if there are more pages? - Kernelstack pages (in the 8K case) must be physically contiguous (for some weird reasons. IIRC some drivers DMA on data on the stack). User-space pages don't have that feature (and there isn't even a mechanism to request that). And for sure it won't work if you have a large userspace stack (and personally I allocate in userspace data on the stack when it makes sense because it doesn't leak and it's faster than malloc()/free()). > > the kernel mode stack. So cannot we simply have a single stack i.e. just > > user mode stack which can also be used for kernel mode execution of process > > after all there wont be any data related to kernel (all would have been > > popped off) in the stack when we are back in user mode? BTW the usual answer is: Simply try it out and see how far you get. > > If you say that its just the stack pointer which is adjusted during pushes > > and pops and the stack content remains intact and user can try to > > increment/decrement stack pointer in order to access kernel data (which is > > stale however) then instead of having two stacks (kernel and user) cannot we > > simply zero out the stack area used by kernel before returing to user mode? One can. But that's an additional "memset()" and how much space do you have to clean? > > and can we save memory by having just one stack? > > It is not just cleaning the stack up. You have to make sure that no other > thread in the userspace accesses it. This means you have to unmap it first. Uuugh, that looks like a quite weird software design if one thread (which has his own stack) actually accesses data on the stack of another thread. Is there a compelling reason not to do that in a (more) sane way? > Doing this on every syscall is probably more expensive than a 4kb page. Even And threads and/or processes has a lot more related data (e.g. "task struct" as such, the file descriptor table, open filedescriptors, ...). The one or two kernel stack pages are not the only thing .... > if it is not, you risk breaking some weird user-space programs which abuse > unused stack space (e.g. functions returning pointers to local variables...). That code is broken anyways as it violates the C standard (and gcc warns nowadays BTW). So IMHO no need to care about it. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
