Linux 中异常是如何处理的？

在程序的执行过程中，因为遇到某种障碍而使 CPU 无法最终访问到相应的物理内存单元，即无法完成从虚拟地址到物理地址映射的时候，CPU 会产生一次缺页异常，从而进行相应的缺页异常处理。基于 CPU 的这一特性，Linux 采用了请求调页（Demand Paging）和写时复制（Copy On Write）的技术

1． 请求调页是一种动态内存分配技术，它把页框的分配推迟到不能再推迟为止。这种技术的动机是：进程开始运行的时候并不访问地址空间中的全部内容。事实上，有一部分地址也许永远也不会被进程所使用。程序的局部性原理也保证了在程序执行的每个阶段，真正使用的进程页只有一小部分，对于临时用不到的页，其所在的页框可以由其它进程使用。因此，请求分页技术增加了系统中的空闲页框的平均数，使内存得到了很好的利用。从另外一个角度来看，在不改变内存大小的情况下，请求分页能够提高系统的吞吐量。当进程要访问的页不在内存中的时候，就通过缺页异常处理将所需页调入内存中。

2． 写时复制主要应用于系统调用fork，父子进程以只读方式共享页框，当其中之一要修改页框时，内核才通过缺页异常处理程序分配一个新的页框，并将页框标记为可写。这种处理方式能够较大的提高系统的性能，这和Linux创建进程的 *** 作过程有一定的关系。在一般情况下，子进程被创建以后会马上通过系统调用execve将一个可执行程序的映象装载进内存中，此时会重新分配子进程的页框。那么，如果fork的时候就对页框进行复制的话，显然是很不合适的。

在上述的两种情况下出现缺页异常，进程运行于用户态，异常处理程序可以让进程从出现异常的指令处恢复执行，使用户感觉不到异常的发生。当然，也会有异常无法正常恢复的情况，这时，异常处理程序会进行一些善后的工作，并结束该进程。也就是说，运行在用户态的进程如果出现缺页异常，不会对 *** 作系统核心的稳定性造成影响。 那么对于运行在核心态的进程如果发生了无法正常恢复的缺页异常，应该如何处理呢？是否会导致系统的崩溃呢？是否能够解决好内核态缺页异常对于 *** 作系统核心的稳定性来说会产生很大的影响，如果一个误 *** 作就会造成系统的Oops，这对于用户来说显然是不能容忍的。本文正是针对这个问题，介绍了一种Linux内核中所采取的解决方法。

在读者继续往下阅读之前，有一点需要先说明一下，本文示例中所选的代码取自于Linux-2.4.0，编译环境是gcc-2.96，objdump的版本是2.11.93.0.2，具体的版本信息可以通过以下的命令进行查询：

$ gcc -v

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs

gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)

$ objdump -v

GNU objdump 2.11.93.0.2 20020207

Copyright 2002 Free Software Foundation, Inc.

需要，可以做以下处理。

1 缺页异常在linux内核处理中占有非常重要的位置，很多linux特性，如写时复制，页框延迟分配，内存回收中的磁盘和内存交换，都需要借助缺页异常来进行，缺页异常处理程序主要处理以下四种情形：

1请求调页: 当进程调用malloc（）之类的函数调用时，并未实际上分配物理内存，而是仅仅分配了一段线性地址空间，在实际访问该页框时才实际去分配物理页框，这样可以节省物理内存的开销，还有一种情况是在内存回收时，该物理页面的内容被写到了磁盘上，被系统回收了，这时候需要再分配页框，并且读取其保存的内容。

2写时复制:当fork()一个进程时，子进程并未完整的复制父进程的地址空间，而是共享相关的资源，父进程的页表被设为只读的，当子进程进行写 *** 作时，会触发缺页异常，从而为子进程分配页框。

3地址范围外的错误:内核访问无效地址，用户态进程访问无效地址等。

4内核访问非连续性地址：用于内核的高端内存映射，高端内存映射仅仅修改了主内核页表的内容，当进程访问内核态时需要将该部分的页表内容复制到自己的进程页表里面。

读深入理解LINUX内核的386页LINUX的请求调页机制，我理解的是这样，请各位大牛指正~~

在程序调入内存执行前，内核先为该进程创建栈的线性地址空间，大小为ulimit -s 所展示的大小。这部分线性空间的页面没有映射到磁盘，属于匿名映射。书上说，读这样线性区的页面LINUX的请求调页给它分配一个零页，这个零页在内核初始化时被静态分配，是长为4096字节的数组，并用0填充。

---