在重游《LDD3》的時候，又發(fā)現(xiàn)了一個當年被我忽略的一句話:
“內(nèi)核具有非常小的棧，它可能只和一個4096字節(jié)大小的頁那樣小”
針對這句話，我簡單地學習了一下進程的“內(nèi)核棧”
什么是進程的“內(nèi)核棧”？
在每一個進程的生命周期中，必然會通過到系統(tǒng)調(diào)用陷入內(nèi)核。在執(zhí)行系統(tǒng)調(diào)用陷入內(nèi)核之后，這些內(nèi)核代碼所使用的棧并不是原先用戶空間中的棧，而是一個內(nèi)核空間的棧，這個稱作進程的“內(nèi)核棧”。
比如，有一個簡單的字符驅(qū)動實現(xiàn)了open方法。在這個驅(qū)動掛載后，應用程序?qū)δ莻€驅(qū)動所對應的設(shè)備節(jié)點執(zhí)行open操作，這個應用程序的open其實就通過glib庫調(diào)用了Linux的open系統(tǒng)調(diào)用，執(zhí)行系統(tǒng)調(diào)用陷入內(nèi)核后，處理器轉(zhuǎn)換為了特權(quán)模式（具體的轉(zhuǎn)換機制因構(gòu)架而異，對于ARM來說普通模式和用戶模式的的棧針（SP）是不同的寄存器），此時使用的棧指針就是內(nèi)核棧指針，他指向內(nèi)核為每個進程分配的內(nèi)核棧空間。
內(nèi)核棧的作用
我個人的理解是：在陷入內(nèi)核后，系統(tǒng)調(diào)用中也是存在函數(shù)調(diào)用和自動變量，這些都需要棧支持。用戶空間的棧顯然不安全，需要內(nèi)核棧的支持。此外，內(nèi)核棧同時用于保存一些系統(tǒng)調(diào)用前的應用層信息（如用戶空間棧指針、系統(tǒng)調(diào)用參數(shù)）。
內(nèi)核棧與進程結(jié)構(gòu)體的關(guān)聯(lián)
每個進程在創(chuàng)建的時候都會得到一個內(nèi)核棧空間，內(nèi)核棧和進程的對應關(guān)系是通過2個結(jié)構(gòu)體中的指針成員來完成的：
（1）struct task_struct
在學習Linux進程管理肯定要學的結(jié)構(gòu)體，在內(nèi)核中代表了一個進程，其中記錄的進程的所有狀態(tài)信息，定義在Sched.h (include\linux)。
其中有一個成員：void *stack;就是指向下面的內(nèi)核棧結(jié)構(gòu)體的“棧底”。
在系統(tǒng)運行的時候，宏current獲得的就是當前進程的struct task_struct結(jié)構(gòu)體。
（2）內(nèi)核棧結(jié)構(gòu)體union thread_union
union thread_union {
struct thread_info thread_info;
unsigned long stack[THREAD_SIZE/sizeof(long)];
};
其中struct thread_info是記錄部分進程信息的結(jié)構(gòu)體，其中包括了進程上下文信息:
/*
* 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;
};
關(guān)鍵是其中的task成員，指向的是所創(chuàng)建的進程的struct task_struct結(jié)構(gòu)體
而其中的stack成員就是內(nèi)核棧。從這里可以看出內(nèi)核棧空間和 thread_info是共用一塊空間的。如果內(nèi)核棧溢出， thread_info就會被摧毀，系統(tǒng)崩潰了～～～
內(nèi)核棧---struct thread_info----struct task_struct三者的關(guān)系入下圖：
內(nèi)核棧的產(chǎn)生
在進程被創(chuàng)建的時候，fork族的系統(tǒng)調(diào)用中會分別為內(nèi)核棧和struct task_struct分配空間，調(diào)用過程是：
fork族的系統(tǒng)調(diào)用--->do_fork--->copy_process--->dup_task_struct
在dup_task_struct函數(shù)中：
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使用內(nèi)核的slab分配器去為所要創(chuàng)建的進程分配struct task_struct的空間
而alloc_thread_info使用內(nèi)核的伙伴系統(tǒng)去為所要創(chuàng)建的進程分配內(nèi)核棧（union thread_union ）空間
注意：
后面的tsk->stack = ti;語句，這就是關(guān)聯(lián)了struct task_struct和內(nèi)核棧
而在setup_thread_stack(tsk, orig);中，關(guān)聯(lián)了內(nèi)核棧和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;
}
內(nèi)核棧的大小
由于是每一個進程都分配一個內(nèi)核?？臻g，所以不可能分配很大。這個大小是構(gòu)架相關(guān)的，一般以頁為單位。其實也就是上面我們看到的THREAD_SIZE，這個值一般為4K或者8K。對于ARM構(gòu)架，這個定義在Thread_info.h (arch\arm\include\asm)，
#define THREAD_SIZE_ORDER 1
#define THREAD_SIZE 8192
#define THREAD_START_SP (THREAD_SIZE - 8)
所以ARM的內(nèi)核棧是8KB
在（內(nèi)核）驅(qū)動編程時需要注意的問題：
由于?？臻g的限制，在編寫的驅(qū)動（特別是被系統(tǒng)調(diào)用使用的底層函數(shù)）中要注意避免對?？臻g消耗較大的代碼，比如遞歸算法、局部自動變量定義的大小等等
