在重遊《LDD3》的時候，又發現了一個當年被我忽略的一句話:
什麼是進程的“內核棧”？
在每一個進程的生命週期中，必然會通過到系統調用陷入內核。在執行系統調用陷入內核之後，這些內核代碼所使用的棧並不是原先用戶空間中的棧，而是一個內核空間的棧，這個稱作進程的“內核棧”。
比如，有一個簡單的字符驅動實現了open方法。在這個驅動掛載後，應用程序對那個驅動所對應的設備節點執行open操作，這個應用程序的open其實就通過glib庫調用了Linux的open系統調用，執行系統調用陷入內核後，處理器轉換爲了特權模式（具體的轉換機制因構架而異，對於ARM來說普通模式和用戶模式的的棧針（SP）是不同的寄存器），此時使用的棧指針就是內核棧指針，他指向內核爲每個進程分配的內核棧空間。
內核棧的作用
我個人的理解是：在陷入內核後，系統調用中也是存在函數調用和自動變量，這些都需要棧支持。用戶空間的棧顯然不安全，需要內核棧的支持。此外，內核棧同時用於保存一些系統調用前的應用層信息（如用戶空間棧指針、系統調用參數）。
內核棧與進程結構體的關聯
每個進程在創建的時候都會得到一個內核棧空間，內核棧和進程的對應關係是通過2個結構體中的指針成員來完成的：
（1）struct task_struct
在學習Linux進程管理肯定要學的結構體，在內核中代表了一個進程，其中記錄的進程的所有狀態信息，定義在Sched.h (include\linux)。
其中有一個成員：void *stack;就是指向下面的內核棧結構體的“棧底”。
在系統運行的時候，宏current獲得的就是當前進程的struct task_struct結構體。
（2）內核棧結構體union thread_union
-
union thread_union {
-
struct thread_info thread_info;
-
unsigned long stack[THREAD_SIZE/sizeof(long)];
- };
其中struct thread_info是記錄部分進程信息的結構體，其中包括了進程上下文信息:
-
/*
-
* low level task data that entry.S needs immediate access to.
-
* __switch_to() assumes
cpu_context follows immediately after cpu_domain.
-
*/
-
struct thread_info {
-
unsigned long flags; /* low
level flags */
-
int preempt_count; /* 0 => preemptable, <0 => bug */
-
mm_segment_t addr_limit; /* address
limit */
-
struct task_struct *task; /* main task structure */
-
struct exec_domain *exec_domain; /* execution
domain */
-
__u32 cpu; /* cpu */
-
__u32 cpu_domain; /* cpu
domain */
-
struct cpu_context_save cpu_context; /* cpu
context */
-
__u32 syscall; /* syscall
number */
-
__u8 used_cp[16]; /* thread
used copro */
-
unsigned long tp_value;
-
struct crunch_state crunchstate;
-
union fp_state fpstate __attribute__((aligned(8)));
-
union vfp_state vfpstate;
-
#ifdef CONFIG_ARM_THUMBEE
-
unsigned long thumbee_state; /* ThumbEE
Handler Base register */
-
#endif
-
struct restart_block restart_block;
- };
關鍵是其中的task成員，指向的是所創建的進程的struct task_struct結構體
而其中的stack成員就是內核棧。從這裏可以看出內核棧空間和 thread_info是共用一塊空間的。如果內核棧溢出， thread_info就會被摧毀，系統崩潰了～～～
內核棧---struct thread_info----struct task_struct三者的關係入下圖：
內核棧的產生
在進程被創建的時候，fork族的系統調用中會分別爲內核棧和struct task_struct分配空間，調用過程是：
-
static struct task_struct *dup_task_struct(struct task_struct *orig)
-
{
-
struct task_struct *tsk;
-
struct thread_info *ti;
-
unsigned long *stackend;
-
-
int err;
-
-
prepare_to_copy(orig);
-
-
tsk = alloc_task_struct();
-
if (!tsk)
-
return NULL;
-
-
ti = alloc_thread_info(tsk);
-
if (!ti) {
-
free_task_struct(tsk);
-
return NULL;
-
}
-
-
err = arch_dup_task_struct(tsk, orig);
-
if (err)
-
goto out;
-
-
tsk->stack = ti;
-
-
err = prop_local_init_single(&tsk->dirties);
-
if (err)
-
goto out;
-
-
setup_thread_stack(tsk, orig);
- ......
其中alloc_task_struct使用內核的slab分配器去爲所要創建的進程分配struct task_struct的空間
而alloc_thread_info使用內核的夥伴系統去爲所要創建的進程分配內核棧（union thread_union ）空間
注意：
後面的tsk->stack = ti;語句，這就是關聯了struct task_struct和內核棧
而在setup_thread_stack(tsk, orig);中，關聯了內核棧和struct task_struct：
-
static inline void setup_thread_stack(struct task_struct *p, struct
task_struct *org)
-
{
-
*task_thread_info(p) = *task_thread_info(org);
-
task_thread_info(p)->task = p;
- }
內核棧的大小
由於是每一個進程都分配一個內核棧空間，所以不可能分配很大。這個大小是構架相關的，一般以頁爲單位。其實也就是上面我們看到的THREAD_SIZE，這個值一般爲4K或者8K。對於ARM構架，這個定義在Thread_info.h (arch\arm\include\asm)，
-
#define THREAD_SIZE_ORDER 1
-
#define THREAD_SIZE 8192
- #define THREAD_START_SP (THREAD_SIZE - 8)
所以ARM的內核棧是8KB
在（內核）驅動編程時需要注意的問題：
由於棧空間的限制，在編寫的驅動（特別是被系統調用使用的底層函數）中要注意避免對棧空間消耗較大的代碼，比如遞歸算法、局部自動變量定義的大小等等
更多關於內核棧的資料請參考：
http://blog.chinaunix.net/uid-26359109-id-3010819.html