简体   繁体   中英

Linux Kernel Stack

What kind of data is stored in the Kernel mode stack of a process ? Is a processes "user mode" call chain stored in the kernel stack ?

Thanks, vIjay

Your kernel call chain, and "no"


The linux kernel is itself a threaded program which works by switching stacks.

So, let's say you do read(0, space, 100); , or perhaps just c = getchar(); , which will eventually turn into a read() .

When linux gets control it will start making function calls, naturally using the kernel stack. It will make calls lower and lower in the kernel until it finally gets to a tty or network layer.

But you haven't typed anything yet!

So it simply switches to another process, one that really is runnable, and it leaves all those function call activation frames on the stack. Eventually you type something and the kernel figures out that your process is now runnable, and when it switches back, again switching stacks, all of those function calls implementing your read(2) can now unwind and eventually return to user mode.

The kernel mode stack of a process is used when the process enters the kernel mode [because of an exception such as system call or fault, or because of a hardware interrupt]. The sequence of steps which the process executes when it enters the kernel mode until it leaves it, is called the kernel control path. State information for the kernel control path is stored in the kernel mode stack of the process. Also, say due to expired time slice, if a context switch occurs, the state of the process-cpu registers are stored on the kernel mode stack so that they can be retrieved when the process is rescheduled on the cpu.

Since the kernel mode stack is only used upon entering the kernel mode, the "user mode" call chain is not stored in this stack.

此问题显示当进程从用户模式转换到内核模式时存储在内核堆栈中的值

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM