内核栈和用户空间栈 [英] kernel stack and user space stack

问题描述

内核栈和用户栈有什么区别?为什么使用内核堆栈?如果在 ISR 中声明了局部变量，它将存储在哪里?每个进程都有自己的内核堆栈吗?那么这两个堆栈之间的过程如何协调?

解决方案

1. 内核栈和用户栈有什么区别?

简而言之，除了使用内存中的不同位置(因此堆栈指针寄存器的值不同)以及通常不同的内存访问保护之外，什么都没有.IE.在用户模式下执行时，即使已映射，内核内存(其中一部分是内核堆栈)也将无法访问.反之亦然，如果内核代码没有明确请求(在 Linux 中，通过诸如 copy_from_user() 之类的函数)，用户内存(包括用户堆栈)通常不能直接访问.

<块引用>

2. 为什么使用[单独的]内核堆栈?

权限与安全的分离.一方面，用户空间程序可以使他们的堆栈(指针)成为他们想要的任何东西，并且通常没有架构要求甚至有一个有效的堆栈.因此，内核不能相信用户空间堆栈指针是有效的或可用的，因此需要在它自己的控制下设置一组.不同的 CPU 架构以不同的方式实现这一点；当权限模式切换发生时，x86 CPU 会自动切换堆栈指针，并且用于不同权限级别的值是可配置的 - 通过特权代码(即仅内核).

<块引用>

3. 如果在 ISR 中声明了局部变量，它将存储在哪里?

在内核堆栈上.内核(即 Linux 内核)不将 ISR 直接挂接到 x86 架构的中断门，而是将中断分派委托给一个通用的内核中断进入/退出机制在调用注册的处理程序之前保存中断前的寄存器状态.CPU 本身在调度中断时可能会执行特权和/或堆栈切换，这是由内核使用/设置的，因此公共中断入口代码已经可以依赖于存在的内核堆栈.
也就是说，在执行内核代码时发生的中断将简单地(继续)使用当时的内核堆栈.如果中断处理程序具有深层嵌套的调用路径，这可能会导致堆栈溢出(如果一个深层内核调用路径被中断并且处理程序导致另一个深层路径；在 Linux 中，文件系统/软件 RAID 代码被具有 iptables 活动的网络代码中断是已知会在未经调整的旧内核中触发此类事件……解决方案是为此类工作负载增加内核堆栈大小).

<块引用>

4. 是否每个进程都有自己的内核堆栈?

不仅仅是每个进程——每个线程都有自己的内核堆栈(事实上，还有自己的用户堆栈).请记住，进程和线程(对于 Linux)之间的唯一区别是多个线程可以共享一个地址空间(形成一个进程).

<块引用>

5. 流程如何在这两个堆栈之间协调?

完全没有 - 它不需要.调度(如何/何时运行不同的线程，如何保存和恢复它们的状态)是操作系统的任务，进程不需要关心这个.随着线程的创建(并且每个进程必须至少有一个线程)，内核为它们创建内核堆栈，而用户空间堆栈要么由用于创建线程的任何机制显式创建/提供(类似于 makecontext 的函数)() 或 pthread_create() 允许调用者指定一个内存区域用于子"线程的堆栈)或继承(通过访问内存克隆，通常称为写入时复制"/COW，在创建新进程时).
也就是说，进程可以影响其线程的调度和/或影响上下文(状态，其中包括线程的堆栈指针).有多种方法:UNIX 信号、setcontext()、pthread_yield()/pthread_cancel()、... - 但这是偏离了原来的问题.

What's the difference between kernel stack and user stack? Why kernel stack is used? If a local variable is declared in an ISR, where it will be stored? Does each process has its own kernel stack? Then how the process coordinates between both these stacks?

解决方案

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.

2. 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).

3. 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).

4. 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).

5. 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.

这篇关于内核栈和用户空间栈的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！