Kernel Stack and User Space Stack

kernel stack and user space stack

  1. What's the difference between kernel stack and user stack ?

In short, nothing - apart from using a different location in memory (and hence a different value for the stack pointer register), and usually different memory access protections. I.e. when executing in user mode, kernel memory (part of which is the kernel stack) will not be accessible even if mapped. Vice versa, without explicitly being requested by the kernel code (in Linux, through functions like copy_from_user()), user memory (including the user stack) is not usually directly accessible.


  1. Why is [ a separate ] kernel stack used ?

Separation of privileges and security. For one, user space programs can make their stack (pointer) anything they want, and there is usually no architectural requirement to even have a valid one. The kernel therefore cannot trust the user space stack pointer to be valid nor usable, and therefore will require one set under its own control. Different CPU architectures implement this in different ways; x86 CPUs automatically switch stack pointers when privilege mode switches occur, and the values to be used for different privilege levels are configurable - by privileged code (i.e. only the kernel).


  1. If a local variable is declared in an ISR, where will it be stored ?

On the kernel stack. The kernel (Linux kernel, that is) does not hook ISRs directly to the x86 architecture's interrupt gates but instead delegates the interrupt dispatch to a common kernel interrupt entry/exit mechanism which saves pre-interrupt register state before calling the registered handler(s). The CPU itself when dispatching an interrupt might execute a privilege and/or stack switch, and this is used/set up by the kernel so that the common interrupt entry code can already rely on a kernel stack being present.

That said, interrupts that occur while executing kernel code will simply (continue to) use the kernel stack in place at that point. This can, if interrupt handlers have deeply nested call paths, lead to stack overflows (if a deep kernel call path is interrupted and the handler causes another deep path; in Linux, filesystem / software RAID code being interrupted by network code with iptables active is known to trigger such in untuned older kernels ... solution is to increase kernel stack sizes for such workloads).


  1. Does each process have its own kernel stack ?

Not just each process - each thread has its own kernel stack (and, in fact, its own user stack as well). Remember the only difference between processes and threads (to Linux) is the fact that multiple threads can share an address space (forming a process).


  1. How does the process coordinate between both these stacks ?

Not at all - it doesn't need to. Scheduling (how / when different threads are being run, how their state is saved and restored) is the operating system's task and processes don't need to concern themselves with this. As threads are created (and each process must have at least one thread), the kernel creates kernel stacks for them, while user space stacks are either explicitly created/provided by whichever mechanism is used to create a thread (functions like makecontext() or pthread_create() allow the caller to specify a memory region to be used for the "child" thread's stack), or inherited (by on-access memory cloning, usually called "copy on write" / COW, when creating a new process).

That said, the process can influence scheduling of its threads and/or influence the context (state, amongst that is the thread's stack pointer). There are multiple ways for this: UNIX signals, setcontext(), pthread_yield() / pthread_cancel(), ... - but this is digressing a bit from the original question.

What's the relationship between kernel space and kernel stack?

The stack structure is usually specified by the processor. Each process usually has one stack per processor mode (user, kernel + any others used by the processor) per process and one interrupt stack per processor (another kernel stack).

Does the process stack I mentioned before consist of user stack and kernel stack?

No. The kernel stack has to be protected from user-mode access.

Is kernel stack part of the kernel space?

It might be or it could be protected memory in the user space.

Are the two stacks separated in a processes' virtual memory address?

yes.

In the code segment: void main(){user_mode_call(); system_call()} do the stack frames of the two calls reside in user stack and kernel stack respectively?

"Code segment" is pedagogical construct. The stack frames of both are in the user stack. System calls invoke a wrapper function that sets up register values then causes an exception that switches the processor to kernel mode. At that point, most processors change the default stack to the kernel mode stack. Parameters have to be passed to system calls because the user stack is not directly accessible through the SP register in kernel mode.

How do kernel switch the kernel stack and user stack?

The TSS have a pointer to kernel stack.

When the INT n is called, the CPU read TSS by referring the GDT.

The TSS have kernel stack pointer and it is set when the thread is created.

The CPU read kernel stack pointer and set esp to kernel stack pointer and compose interrupt frame in kernel stack.

Does thread occupies its independent kernel space?

  1. Every process has its own kernel stack(space)

Yes.


  1. Thread has independent stack memory and share the other (heap code etc...)

Yes, roughly.


  1. What are inside in the Kernel stack is some formal information for its process' later context switch

No. The kernel stack associated with a thread is used as a call stack during the execution of syscalls performed on behalf of that thread. As far as I am aware, it is not involved in context switching between threads, and not directly in switches from user mode to kernel mode.

If Thread only has its own stack memory, how does OS can manage
thread's context switch?

The same way that it manages context switches among processes. The kernel maintains the information needed to do so (which is not particularly much on a per-thread basis), albeit not on threads' kernel stacks as far as I am aware. But this is perhaps splitting hairs over terminology -- you seem to have identified "kernel stack" with "kernel space", but the kernel maintains more per-thread data than just a kernel stack.

If process A has 10 threads, all those
threads' information is written in process A's kernel space? wouldn't
be cause a lack of memory in kernel space when there are too many
threads?

I'm not sure you have quite the right view of things, but yes, the number of threads that can be alive simultaneously is limited by available resources. The details are a property of the kernel and threading implementations. There can be both per-process and global limits.

In practice, processes running on Linux and using native threads can have thousands of threads if available memory (physical and virtual) is sufficient. Kernel stacks are usually only a few kB each; these are not ordinarily the limiting factor.



Related Topics



Leave a reply



Submit