在Linux中，系统调用是用户空间访问内核的唯一手段，它们是内核唯一的合法入口。实际上，其他的像设备文件和/proc之类的方式，最终也还是要通过系统调用进行的。

       一般情况下，应用程序通过应用编程接口(API)而不是直接通过系统调用来编程，而且这种编程接口实际上并不需要和内核提供的系统调用对应。一个API定义了一组应用程序使用的编程接口。它们可以实现成一个系统调用，也可以通过调用多个系统调用来实现，即使不使用任何系统调用也不存在问题。实际上，API可以在各种不同的操作系统上实现，给应用程序提供完全相同的接口，而它们本身在这些系统上的实现却可能迥异。

       在Unix世界中，最流行的应用编程接口是基于POSIX标准的，Linux是与POSIX兼容的。

       从程序员的角度看，他们只需要给API打交道就可以了，而内核只跟系统调用打交道；库函数及应用程序是怎么使用系统调用不是内核关心的。

       系统调用(在linux中常称作syscalls)通常通过函数进行调用。它们通常都需要定义一个或几个参数(输入)而且可能产生一些副作用。这些副作用通过一个long类型的返回值来表示成功(0值)或者错误(负值)。在系统调用出现错误的时候会把错误码写入errno全局变量。通过调用perror()函数，可以把该变量翻译成用户可以理解的错误字符串。

       系统调用的实现有两个特别之处：1）函数声明中都有asmlinkage限定词，用于通知编译器仅从栈中提取该函数的参数。2）系统调用getXXX()在内核中被定义为sys_getXXX()。这是Linux中所有系统调用都应该遵守的命名规则。

       系统调用号：在linux中，每个系统调用都赋予一个系统调用号，通过这个独一无二的号就可以关联系统调用。当用户空间的进程执行一个系统调用的时候，这个系统调用号就被用来指明到底要执行哪个系统调用；进程不会提及系统调用的名称。系统调用号一旦分配就不能再有任何变更(否则编译好的应用程序就会崩溃)，如果一个系统调用被删除，它所占用的系统调用号也不允许被回收利用。Linux有一个"未使用"系统调用sys_ni_syscall(),它除了返回-ENOSYS外不做任何其他工作，这个错误号就是专门针对无效的系统调用而设的。虽然很罕见，但如果有一个系统调用被删除，这个函数就要负责“填补空位”。

       内核记录了系统调用表中所有已注册过的系统调用的列表，存储在sys_call_table中。它与体系结构有关，一般在entry.s中定义。这个表中为每一个有效的系统调用指定了唯一的系统调用号。

       用户空间的程序无法直接执行内核代码。它们不能直接调用内核空间的函数，因为内核驻留在受保护的地址空间上，应用程序应该以某种方式通知系统，告诉内核自己需要执行一个系统调用，系统系统切换到内核态，这样内核就可以代表应用程序来执行该系统调用了。这种通知内核的机制是通过软中断实现的。x86系统上的软中断由int$0x80指令产生。这条指令会触发一个异常导致系统切换到内核态并执行第128号异常处理程序，而该程序正是系统调用处理程序，名字叫system_call().它与硬件体系结构紧密相关，通常在entry.s文件中通过汇编语言编写。

       所有的系统调用陷入内核的方式都是一样的，所以仅仅是陷入内核空间是不够的。因此必须把系统调用号一并传给内核。在x86上，这个传递动作是通过在触发软中断前把调用号装入eax寄存器实现的。这样系统调用处理程序一旦运行，就可以从eax中得到数据。上述所说的system_call()通过将给定的系统调用号与NR_syscalls做比较来检查其有效性。如果它大于或者等于NR_syscalls，该函数就返回-ENOSYS.否则，就执行相应的系统调用：call *sys_call_table(, %eax, 4);

       由于系统调用表中的表项是以32位(4字节)类型存放的，所以内核需要将给定的系统调用号乘以4，然后用所得到的结果在该表中查询器位置。如图图一所示：

     上面已经提到，除了系统调用号以外，还需要一些外部的参数输入。最简单的办法就是像传递系统调用号一样把这些参数也存放在寄存器里。在x86系统上ebx,ecx,edx,esi和edi按照顺序存放前5个参数。需要六个或六个以上参数的情况不多见，此时，应该用一个单独的寄存器存放指向所有这些参数在用户空间地址的指针。给用户空间的返回值也通过寄存器传递。在x86系统上，它存放在eax寄存器中。

       系统调用必须仔细检查它们所有的参数是否合法有效。系统调用在内核空间执行。如果任由用户将不合法的输入传递给内核，那么系统的安全和稳定将面临极大的考验。最重要的一种检查就是检查用户提供的指针是否有效，内核在接收一个用户空间的指针之前，内核必须要保证：

       内核提供了两种方法来完成必须的检查和内核空间与用户空间之间数据的来回拷贝。这两个方法必须有一个被调用。

       内核在执行系统调用的时候处于进程上下文，current指针指向当前任务，即引发系统调用的那个进程。在进程上下文中，内核可以休眠(比如在系统调用阻塞或显式调用schedule()的时候)并且可以被抢占。当系统调用返回的时候，控制权仍然在system_call()中，它最终会负责切换到用户空间并让用户进程继续执行下去。

       给linux添加一个系统调用时间很简单的事情，怎么设计和实现一个系统调用是难题所在。实现系统调用的第一步是决定它的用途，这个用途是明确且唯一的，不要尝试编写多用途的系统调用。ioctl则是一个反面教材。新系统调用的参数，返回值和错误码该是什么，这些都很关键。一旦一个系统调用编写完成后，把它注册成为一个正式的系统调用是件琐碎的工作，一般下面几步：

       通常，系统调用靠C库支持，用户程序通过包含标准头文件并和C库链接，就可以使用系统调用(或者使用库函数，再由库函数实际调用)。庆幸的是linux本身提供了一组宏用于直接对系统调用进行访问。它会设置好寄存器并调用int $0x80指令。这些宏是_syscalln(),其中n的范围是从0到6.代表需要传递给系统调用的参数个数。这是由于该宏必须了解到底有多少参数按照什么次序压入寄存器。以open系统调用为例：

    这样，应用程序就可以直接使用open().调用open()系统调用直接把上面的宏放置在应用程序中就可以了。对于每个宏来说，都有2+2*n个参数。每个参数的意义简单明了，这里就不详细说明了。

1. /**  
2.  * list_for_each    -   iterate over a list  
3.  * @pos:    the &struct list_head to use as a loop counter.  
4.  * @head:   the head for your list.  
5.  */  
6. #define list_for_each(pos, head) \  
7.     for (pos = (head)->next, prefetch(pos->next); pos != (head); \  
8.         pos = pos->next, prefetch(pos->next))  

list_for_each_safe()的定义：

1. /**  
2.  * list_for_each_safe   -   iterate over a list safe against removal of list entry  
3.  * @pos:    the &struct list_head to use as a loop counter.  
4.  * @n:      another &struct list_head to use as temporary storage  
5.  * @head:   the head for your list.  
6.  */  
7. #define list_for_each_safe(pos, n, head) \  
8.     for (pos = (head)->next, n = pos->next; pos != (head); \  
9.         pos = n, n = pos->next)  

由上面两个对比来看，list_for_each_safe()函数比list_for_each()多了一个中间变量n

当在遍历的过程中需要删除结点时，来看一下会出现什么情况：

list_for_each()：list_del(pos)将pos的前后指针指向undefined state,导致kernel panic，另如果list_del_init(pos)将pos前后指针指向自身，导致死循环。

list_for_each_safe()：首先将pos的后指针缓存到n，处理一个流程后再赋回pos，避免了这种情况发生。

因此之遍历链表不删除结点时，可以使用list_for_each()，而当由删除结点操作时，则要使用list_for_each_safe()。

其他带safe的处理也是基于这个原因。

链表是一种常用的组织有序数据的数据结构，它通过指针将一系列数据节点连接成一条数据链，是线性表的一种重要实现方式。相对于数组，链表具有更好的动态性，建立链表时无需预先知道数据总量，可以随机分配空间，可以高效地在链表中的任意位置实时插入或删除数据。链表的开销主要是访问的顺序性和组织链的空间损失。

通常链表数据结构至少应包含两个域：数据域和指针域，数据域用于存储数据，指针域用于建立与下一个节点的联系。按照指针域的组织以及各个节点之间的联系形式，链表又可以分为单链表、双链表、循环链表等多种类型，下面分别给出这几类常见链表类型的示意图：

1． 单链表

单链表是最简单的一类链表，它的特点是仅有一个指针域指向后继节点（next），因此，对单链表的遍历只能从头至尾（通常是NULL空指针）顺序进行。

2． 双链表

通过设计前驱和后继两个指针域，双链表可以从两个方向遍历，这是它区别于单链表的地方。如果打乱前驱、后继的依赖关系，就可以构成"二叉树"；如果再让首节点的前驱指向链表尾节点、尾节点的后继指向首节点（如图2中虚线部分），就构成了循环链表；如果设计更多的指针域，就可以构成各种复杂的树状数据结构。

3． 循环链表

循环链表的特点是尾节点的后继指向首节点。前面已经给出了双循环链表的示意图，它的特点是从任意一个节点出发，沿两个方向的任何一个，都能找到链表中的任意一个数据。如果去掉前驱指针，就是单循环链表。

在Linux内核中使用了大量的链表结构来组织数据，包括设备列表以及各种功能模块中的数据组织。这些链表大多采用在[include/linux/list.h]实现的一个相当精彩的链表数据结构。本文的后继部分就将通过示例详细介绍这一数据结构的组织和使用。

二、 Linux 2.6内核链表数据结构的实现

尽管这里使用2.6内核作为讲解的基础，但实际上2.4内核中的链表结构和2.6并没有什么区别。不同之处在于2.6扩充了两种链表数据结构：链表的读拷贝更新（rcu）和HASH链表（hlist）。这两种扩展都是基于最基本的list结构，因此，本文主要介绍基本链表结构，然后再简要介绍一下rcu和hlist。

链表数据结构的定义很简单（节选自[include/linux/list.h]，以下所有代码，除非加以说明，其余均取自该文件）：

struct list_head {
	struct list_head *next, *prev;
};

list_head结构包含两个指向list_head结构的指针prev和next，由此可见，内核的链表具备双链表功能，实际上，通常它都组织成双循环链表。

和第一节介绍的双链表结构模型不同，这里的list_head没有数据域。在Linux内核链表中，不是在链表结构中包含数据，而是在数据结构中包含链表节点。

在数据结构课本中，链表的经典定义方式通常是这样的（以单链表为例）：

struct list_node {
	struct list_node *next;
	ElemType	data;
};

因为ElemType的缘故，对每一种数据项类型都需要定义各自的链表结构。有经验的C++程序员应该知道，标准模板库中的<list>采用的是C++ Template，利用模板抽象出和数据项类型无关的链表操作接口。

在Linux内核链表中，需要用链表组织起来的数据通常会包含一个struct list_head成员，例如在[include/linux/netfilter.h]中定义了一个nf_sockopt_ops结构来描述Netfilter为某一协议族准备的getsockopt/setsockopt接口，其中就有一个（struct list_head list）成员，各个协议族的nf_sockopt_ops结构都通过这个list成员组织在一个链表中，表头是定义在[net/core/netfilter.c]中的nf_sockopts（struct list_head）。从下图中我们可以看到，这种通用的链表结构避免了为每个数据项类型定义自己的链表的麻烦。Linux的简捷实用、不求完美和标准的风格，在这里体现得相当充分。

三、 链表操作接口

1. 声明和初始化

实际上Linux只定义了链表节点，并没有专门定义链表头，那么一个链表结构是如何建立起来的呢？让我们来看看LIST_HEAD()这个宏：

#define LIST_HEAD_INIT(name) { &(name), &(name) }
#define LIST_HEAD(name) struct list_head name = LIST_HEAD_INIT(name)

当我们用LIST_HEAD(nf_sockopts)声明一个名为nf_sockopts的链表头时，它的next、prev指针都初始化为指向自己，这样，我们就有了一个空链表，因为Linux用头指针的next是否指向自己来判断链表是否为空：

static inline int list_empty(const struct list_head *head)
{
		return head->next == head;
}

除了用LIST_HEAD()宏在声明的时候初始化一个链表以外，Linux还提供了一个INIT_LIST_HEAD宏用于运行时初始化链表：

#define INIT_LIST_HEAD(ptr) do { \
	(ptr)->next = (ptr); (ptr)->prev = (ptr); \
} while (0)

我们用INIT_LIST_HEAD(&nf_sockopts)来使用它。

2. 插入/删除/合并

a) 插入

对链表的插入操作有两种：在表头插入和在表尾插入。Linux为此提供了两个接口：

static inline void list_add(struct list_head *new, struct list_head *head);
static inline void list_add_tail(struct list_head *new, struct list_head *head);

因为Linux链表是循环表，且表头的next、prev分别指向链表中的第一个和最末一个节点，所以，list_add和list_add_tail的区别并不大，实际上，Linux分别用

__list_add(new, head, head->next);

和

__list_add(new, head->prev, head);

来实现两个接口，可见，在表头插入是插入在head之后，而在表尾插入是插入在head->prev之后。

假设有一个新nf_sockopt_ops结构变量new_sockopt需要添加到nf_sockopts链表头，我们应当这样操作：

list_add(&new_sockopt.list, &nf_sockopts);

从这里我们看出，nf_sockopts链表中记录的并不是new_sockopt的地址，而是其中的list元素的地址。如何通过链表访问到new_sockopt呢？下面会有详细介绍。

b) 删除

static inline void list_del(struct list_head *entry);

当我们需要删除nf_sockopts链表中添加的new_sockopt项时，我们这么操作：

list_del(&new_sockopt.list);

被剔除下来的new_sockopt.list，prev、next指针分别被设为LIST_POSITION2和LIST_POSITION1两个特殊值，这样设置是为了保证不在链表中的节点项不可访问--对LIST_POSITION1和LIST_POSITION2的访问都将引起页故障。与之相对应，list_del_init()函数将节点从链表中解下来之后，调用LIST_INIT_HEAD()将节点置为空链状态。

c) 搬移

Linux提供了将原本属于一个链表的节点移动到另一个链表的操作，并根据插入到新链表的位置分为两类：

static inline void list_move(struct list_head *list, struct list_head *head);
static inline void list_move_tail(struct list_head *list, struct list_head *head);

例如list_move(&new_sockopt.list,&nf_sockopts)会把new_sockopt从它所在的链表上删除，并将其再链入nf_sockopts的表头。

d) 合并

除了针对节点的插入、删除操作，Linux链表还提供了整个链表的插入功能：

static inline void list_splice(struct list_head *list, struct list_head *head);

假设当前有两个链表，表头分别是list1和list2（都是struct list_head变量），当调用list_splice(&list1,&list2)时，只要list1非空，list1链表的内容将被挂接在list2链表上，位于list2和list2.next（原list2表的第一个节点）之间。新list2链表将以原list1表的第一个节点为首节点，而尾节点不变。如图（虚箭头为next指针）：

当list1被挂接到list2之后，作为原表头指针的list1的next、prev仍然指向原来的节点，为了避免引起混乱，Linux提供了一个list_splice_init()函数：

static inline void list_splice_init(struct list_head *list, struct list_head *head);
	

该函数在将list合并到head链表的基础上，调用INIT_LIST_HEAD(list)将list设置为空链。

3. 遍历

遍历是链表最经常的操作之一，为了方便核心应用遍历链表，Linux链表将遍历操作抽象成几个宏。在介绍遍历宏之前，我们先看看如何从链表中访问到我们真正需要的数据项。

a) 由链表节点到数据项变量

我们知道，Linux链表中仅保存了数据项结构中list_head成员变量的地址，那么我们如何通过这个list_head成员访问到作为它的所有者的节点数据呢？Linux为此提供了一个list_entry(ptr,type,member)宏，其中ptr是指向该数据中list_head成员的指针，也就是存储在链表中的地址值，type是数据项的类型，member则是数据项类型定义中list_head成员的变量名，例如，我们要访问nf_sockopts链表中首个nf_sockopt_ops变量，则如此调用：

list_entry(nf_sockopts->next, struct nf_sockopt_ops, list);

这里"list"正是nf_sockopt_ops结构中定义的用于链表操作的节点成员变量名。

list_entry的使用相当简单，相比之下，它的实现则有一些难懂：

#define list_entry(ptr, type, member) container_of(ptr, type, member)
container_of宏定义在[include/linux/kernel.h]中：
#define container_of(ptr, type, member) ({			\
        const typeof( ((type *)0)->member ) *__mptr = (ptr);	\
        (type *)( (char *)__mptr - offsetof(type,member) );})
offsetof宏定义在[include/linux/stddef.h]中：
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)

size_t最终定义为unsigned int（i386）。

这里使用的是一个利用编译器技术的小技巧，即先求得结构成员在与结构中的偏移量，然后根据成员变量的地址反过来得出属主结构变量的地址。

container_of()和offsetof()并不仅用于链表操作，这里最有趣的地方是((type *)0)->member，它将0地址强制"转换"为type结构的指针，再访问到type结构中的member成员。在container_of宏中，它用来给typeof()提供参数（typeof()是gcc的扩展，和sizeof()类似），以获得member成员的数据类型；在offsetof()中，这个member成员的地址实际上就是type数据结构中member成员相对于结构变量的偏移量。

如果这么说还不好理解的话，不妨看看下面这张图：

对于给定一个结构，offsetof(type,member)是一个常量，list_entry()正是利用这个不变的偏移量来求得链表数据项的变量地址。

b) 遍历宏

在[net/core/netfilter.c]的nf_register_sockopt()函数中有这么一段话：

		……
struct list_head *i;
……
	list_for_each(i, &nf_sockopts) {
		struct nf_sockopt_ops *ops = (struct nf_sockopt_ops *)i;
		……
	}
	……
	

函数首先定义一个(struct list_head *)指针变量i，然后调用list_for_each(i,&nf_sockopts)进行遍历。在[include/linux/list.h]中，list_for_each()宏是这么定义的：

        	#define list_for_each(pos, head) \
	for (pos = (head)->next, prefetch(pos->next); pos != (head); \
        	pos = pos->next, prefetch(pos->next))
        	

它实际上是一个for循环，利用传入的pos作为循环变量，从表头head开始，逐项向后（next方向）移动pos，直至又回到head（prefetch()可以不考虑，用于预取以提高遍历速度）。

那么在nf_register_sockopt()中实际上就是遍历nf_sockopts链表。为什么能直接将获得的list_head成员变量地址当成struct nf_sockopt_ops数据项变量的地址呢？我们注意到在struct nf_sockopt_ops结构中，list是其中的第一项成员，因此，它的地址也就是结构变量的地址。更规范的获得数据变量地址的用法应该是：

struct nf_sockopt_ops *ops = list_entry(i, struct nf_sockopt_ops, list);

大多数情况下，遍历链表的时候都需要获得链表节点数据项，也就是说list_for_each()和list_entry()总是同时使用。对此Linux给出了一个list_for_each_entry()宏：

#define list_for_each_entry(pos, head, member)		……

与list_for_each()不同，这里的pos是数据项结构指针类型，而不是(struct list_head *)。nf_register_sockopt()函数可以利用这个宏而设计得更简单：

……
struct nf_sockopt_ops *ops;
list_for_each_entry(ops,&nf_sockopts,list){
	……
}
……

某些应用需要反向遍历链表，Linux提供了list_for_each_prev()和list_for_each_entry_reverse()来完成这一操作，使用方法和上面介绍的list_for_each()、list_for_each_entry()完全相同。

如果遍历不是从链表头开始，而是从已知的某个节点pos开始，则可以使用list_for_each_entry_continue(pos,head,member)。有时还会出现这种需求，即经过一系列计算后，如果pos有值，则从pos开始遍历，如果没有，则从链表头开始，为此，Linux专门提供了一个list_prepare_entry(pos,head,member)宏，将它的返回值作为list_for_each_entry_continue()的pos参数，就可以满足这一要求。

4. 安全性考虑

在并发执行的环境下，链表操作通常都应该考虑同步安全性问题，为了方便，Linux将这一操作留给应用自己处理。Linux链表自己考虑的安全性主要有两个方面：

a) list_empty()判断

基本的list_empty()仅以头指针的next是否指向自己来判断链表是否为空，Linux链表另行提供了一个list_empty_careful()宏，它同时判断头指针的next和prev，仅当两者都指向自己时才返回真。这主要是为了应付另一个cpu正在处理同一个链表而造成next、prev不一致的情况。但代码注释也承认，这一安全保障能力有限：除非其他cpu的链表操作只有list_del_init()，否则仍然不能保证安全，也就是说，还是需要加锁保护。

b) 遍历时节点删除

前面介绍了用于链表遍历的几个宏，它们都是通过移动pos指针来达到遍历的目的。但如果遍历的操作中包含删除pos指针所指向的节点，pos指针的移动就会被中断，因为list_del(pos)将把pos的next、prev置成LIST_POSITION2和LIST_POSITION1的特殊值。

当然，调用者完全可以自己缓存next指针使遍历操作能够连贯起来，但为了编程的一致性，Linux链表仍然提供了两个对应于基本遍历操作的"_safe"接口：list_for_each_safe(pos, n, head)、list_for_each_entry_safe(pos, n, head, member)，它们要求调用者另外提供一个与pos同类型的指针n，在for循环中暂存pos下一个节点的地址，避免因pos节点被释放而造成的断链。

四、 扩展

1. hlist

精益求精的Linux链表设计者（因为list.h没有署名，所以很可能就是Linus Torvalds）认为双头（next、prev）的双链表对于HASH表来说"过于浪费"，因而另行设计了一套用于HASH表应用的hlist数据结构--单指针表头双循环链表，从上图可以看出，hlist的表头仅有一个指向首节点的指针，而没有指向尾节点的指针，这样在可能是海量的HASH表中存储的表头就能减少一半的空间消耗。

因为表头和节点的数据结构不同，插入操作如果发生在表头和首节点之间，以往的方法就行不通了：表头的first指针必须修改指向新插入的节点，却不能使用类似list_add()这样统一的描述。为此，hlist节点的prev不再是指向前一个节点的指针，而是指向前一个节点（可能是表头）中的next（对于表头则是first）指针（struct list_head **pprev），从而在表头插入的操作可以通过一致的"*(node->pprev)"访问和修改前驱节点的next（或first）指针。

2. read-copy update

在Linux链表功能接口中还有一系列以"_rcu"结尾的宏，与以上介绍的很多函数一一对应。RCU（Read-Copy Update）是2.5/2.6内核中引入的新技术，它通过延迟写操作来提高同步性能。

我们知道，系统中数据读取操作远多于写操作，而rwlock机制在smp环境下随着处理机增多性能会迅速下降（见参考资料4）。针对这一应用背景，IBM Linux技术中心的Paul E. McKenney提出了"读拷贝更新"的技术，并将其应用于Linux内核中。RCU技术的核心是写操作分为写-更新两步，允许读操作在任何时候无阻访问，当系统有写操作时，更新动作一直延迟到对该数据的所有读操作完成为止。Linux链表中的RCU功能只是Linux RCU的很小一部分，对于RCU的实现分析已超出了本文所及，有兴趣的读者可以自行参阅本文的参考资料；而对RCU链表的使用和基本链表的使用方法基本相同。

五、 示例

附件中的程序除了能正向、反向输出文件以外，并无实际作用，仅用于演示Linux链表的使用。

为了简便，例子采用的是用户态程序模板，如果需要运行，可采用如下命令编译：

gcc -D__KERNEL__ -I/usr/src/linux-2.6.7/include pfile.c -o pfile

因为内核链表限制在内核态使用，但实际上对于数据结构本身而言并非只能在核态运行，因此，在笔者的编译中使用"-D__KERNEL__"开关"欺骗"编译器。

参考资料

1. 维基百科 http://zh.wikipedia.org，一个在GNU Documentation License下发布的网络辞典，自由软件理念的延伸，本文的"链表"概念即使用它的版本。
2. 《Linux内核情景分析》，毛德操先生的这本关于Linux内核的巨著几乎可以回答绝大部分关于内核的问题，其中也包括内核链表的几个关键数据结构。
3. Linux内核2.6.7源代码，所有不明白的问题，只要潜心看代码，总能清楚。
4. Kernel Korner: Using RCU in the Linux 2.5 Kernel，RCU主要开发者Paul McKenney 2003年10月发表于Linux Journal上的一篇介绍RCU的文章。在 http://www.rdrop.com/users/paulmck/rclock/上可以获得更多关于RCU的帮助。

关于作者

用于进程退出的系统调用有两个exit和exit_group，exit只是终止某个进程，而exit_group整个线程中的进程。它们在内核中的服务函数分别为sys_exit和sys_exit_group，它们又分别调用了do_exit和do_group_exit。而do_group最终又调用了do_exit。

do_exit定义在kernel/exit.c中：

僵死进程：僵死进程是一个进程已经退出，它的内存和资源已经释放掉了，但是位了时系统在它退出后能够获得它的退出状态等信息，它的进程描述符仍然保留。

一个进程退出时，它的父进程会接收到一个SIGCHLD信号，一般情况下这个信号的处理函数会执行wait系列函数等待子进程的结束。从子进程退出到父进程调用wait(子进程结束)的这段时间，子进程称为僵死进程。执行ps –ef命令以“z”结尾的为僵死进程。

僵死进程很特殊，它没有任何可执行代码，不会被调度，只有一个进程描述符用来记录退出等状态，除此之外不再占用其他任何资源。

如果僵死进程的父进程没有调用wait，则该进程会一直处于僵死状态。如果父进程结束，内核会在当前线程组里为其找一个父进程，如果没找到则把init作为其父进程，此时新的父进程将负责清楚其进程。如果父进程一直不结束，该进程会一直僵死。在root下用kill -9 也不能将其杀死。

下面只对do_exit重点地方解析下： 

1. struct task_struct *tsk = current;//获取当前要释放进程的进程描述符   
   

   
   exit_signals(tsk);  /* sets PF_EXITING 以免内和其他部分访问该进程*/   
   
   exit_mm(tsk);  
2.   
3.     if (group_dead)  
4.         acct_process();  
5.     trace_sched_process_exit(tsk);  
6.   
7.     exit_sem(tsk);  
8.     exit_files(tsk);  
9.     exit_fs(tsk);  
10.     check_stack_usage();  
    
    
11. /*更新父子关系，并告诉父进程正在退出*/  
12.     exit_notify(tsk, group_dead);
13. /*切换到其他进程*/  
14.     schedule(); 
15.     exit_thread();  
    
    
    

    第1个Child process 6427, data 10是因为子进程创建时task_struct的mm直接拷贝自parent的mm；第2个Child process 6427, data 20是因为子进程进行了“写时拷贝”，有了自己的dataa；第3个Parent process 6426, data 10输出10是因为子进程的data和父进程的data不是同一份。
    如果把上述程序改为：