[分享]《Linux内核注释》

1万主题	49 听众	2万积分

TA的每日心情

	奋斗 2024-6-23 05:14

签到天数: 1043 天

[LV.10]以坛为家III

群组: 万里江山

群组: sas讨论小组

群组: C 语言讨论组

群组: Matlab讨论组

电梯直达

1^#

发表于 2005-3-4 21:40 |只看该作者 |正序浏览

|招呼Ta 关注Ta

align=center>介绍
<

align=left> 《Linux内核注释》旨在给程序员和学生提供比以前更详细和更易理解的Linux内核代码注释。作者分析了核心代码，并对重要的函数、系统调用和数据结构提供了大量的注释。
<

align=left> 对《注释》系列丛书的写作灵感都来源于John Lions所著的大量流行的《Lions' Commentary on Unix》一书。无数的计算机专业的学生在复制和使用这本书。这本书对AT&T的Unix操作系统的早期版本的内幕进行了深刻的剖析。
<

align=left> 《Liunx内核注释》同样提供了对流行的功能强大的Liunx操作系统的结构和函数实现的内幕介绍。本书的主要目标是：
<

align=left> 1.提供一个最新的和完整的服务器版本的完整源代码。（这本书分析的版本是<st1:chsdate w:st="on" IsROCDate="False" IsLunarDate="False" Day="30" Month="12" Year="1899">2.2.5</st1:chsdate>版,也是写这本书时发布的最新版本。）
<

align=left> 2.提供一个对每个子系统功能的一般性概述。
<

align=left> 3.研究各个子系统主要的函数和数据结构。
<

align=left> 4.对开发者应怎样通过修改源代码来改进和扩展内核提出建议。
<

align=left> 本书的最后一项目标—定制--是你学习内核代码的最有说服力的原因。通过理解内核是怎样工作的，你能够编写自己的代码用以在你的操作系统中实现所需要的功能。如果允许其他人共享你的改进，你的代码甚至会在官方发行的内核代码中出现，被全世界数百万计的人们所使用。
<

align=left> 开放源代码是指让开发者研究源代码并实现功能性扩展。Linux是全世界成长最快的操作系统,开放源代码是其主要的原因之一。从玩游戏，到网上冲浪，到为大大小小的ISP们提供稳定的Web服务器平台以至解决最庞大的科学难题，Linux都能胜任全部工作。它之所以能如此强大是因为有像你一样的开发者在研究、学习并且扩充这个系统。
<

align=left>你能从本书中学到什么
<

align=left> 这本书集中解释了Linux内核源代码的核心中专用代码行是如何运行的。你将学习到内核最内部的子系统是怎样构造和这种构造能够实现系统功能的理由。
<

align=left> 本书的第一部分以易于阅读和交叉引用的格式复制了一个经过筛选的linux 内核源代码的子集。在这本书稍后的注释中，无论一行代码在何处被引用，你都会在这一行前面发现一个小箭头。这个箭头指出了对此行进行注释处的页号。
<

align=left> 源代码后是这本书的第二部分，即注释部分，注释部分对源代码进行了讨论。注释部分的每一章讨论了一个不同的内核子系统，或者是其它的功能性逻辑组件，例如系统调用或内存管理。注释部分大量的行号引用为你指明了所讨论代码行的确切行号。
<

align=left> 在本书正文后的附录部分,简洁地覆盖了自本书主要部分完成以后内核的变化。在附录中还包含了被内核用做软件许可证的完整的GNU常规公众许可证。最后,本书为你提供了一个索引。通过该索引你可以查询术语或主题。这将让你更快更有效的使用这本参考工具书。
<

align=left>本书的使用对象
<

align=left> 本书假设你能阅读C语言的代码,不怕偶尔读一些汇编语言代码。并且你想知道一个快速的、坚固的、可靠的、健壮的、现代的、实用的操作系统是如何工作的。一些读者也许是这样的程序员,他们想为前进中的Linux内核发展工作提供他们自己的改进和添加内容。
<

align=left>如何使用本书
<

align=left> 用最适合你自己的方法放松地去看这本《linux 内核注释》。因为写这本书的目的是为提供一个参考资料，你不必从头看到尾。因为注释和代码是一一对应的，你可以从另外一个方向接近内核。
<

align=left> 欢迎你对我的第一本书提出意见。你可以通过e-mail和我联系。地址是：<a href="mailtlckc@ScottMaxwell.org" target="_blank" >lckc@ScottMaxwell.org</A>。勘误表、更新和其它一些有用信息可以通过访问 <a href="http://www.scottmaxwell.org/lckc.html" target="_blank" >http://www.ScottMaxwell.org/lckc.html</A> 得到。
<

align=left>

zan

转播0 淘帖0 分享0 收藏0 支持0 反对0 微信

1万主题	49 听众	2万积分

TA的每日心情

	奋斗 2024-6-23 05:14

签到天数: 1043 天

[LV.10]以坛为家III

群组: 万里江山

群组: sas讨论小组

群组: C 语言讨论组

群组: Matlab讨论组

19^#

发表于 2005-3-4 22:33 |只看该作者 |招呼Ta 关注Ta

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">31146：与前边的情况类似，从用户空间中复制新值，而且结果以NUL来结束。不过在这种情形下，不从用户空间复制NUL字节是一种正确的做法，因为把它从用户空间复制进来要比仅仅在data的适当字节安排一个NUL效率低。而且以这种方式，即使输入不是NUL结束的，table->data也要如此。当然，从newval读出的字符串可能已经是NUL结束的，在那种情况里第31154行的赋值就是多余的。这还是另一种情况，直接完成工作比检查需要是否执行它还要快。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">31156：返回0表示成功。相反，返回的值应该为正数，以便30618行代码认为结果是成功的。而又相反，调用代码认为sysctl_string想让缺省处理发生，然后它就继续从用户空间再次复制多余的数据。<

12pt 0cm 3.2pt">sysctl_intvec<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">31163：sysctl_intvec是在kernel/sysctl.c里定义的另一个策略例程。它确保假如调用程序正在写入表项，所有被写的int都应位于某个最小和最大值之间。（顺便提及一下，sysctl_intvec在这个文件里只被使用了一次——在第30414行——尽管它被广泛的用于本书所没有包括的内核的其它代码之中。）<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">31170：如果新的欲写数据总量不符合一个int大小的边界，它就无效，所以尝试被抛弃。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">31173：假如表项没有指定一组最大或最小值，输入的值就永远不可能超出范围，这样调用程序里的普通写代码（do_sysctl_strategy，30603行）就足够好了。因此在这种情况里sysctl_intvec返回0。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">31184：进行循环以确保所有来自输入数组的值都位于适当范围之内。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">31186：这行代码不检查get_user的返回值——没有迫切的需要去这样做。如果当不能读取一个输入内存位置时，sysctl_intvec返回0（成功），那么当它试图读取整个数组时do_sysctl_strategy就会注意到这个问题。作为另一选择，假如get_user无法读取内存位置，无用信息（garbage）可能在value里结束并且数值可能会不正确的被抛弃。在此情况里，调用程序将得到一个EINVAL错误而不是EFAULT错误，这只是一个小缺陷（bug）。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">31187：注意这一行不会被折磨第31033行相似代码的缺陷所困扰，该行中在最小值和最大值之上进行的并行循环会产生不同步的情况。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> 这一行代码能够避免位于31033行的缺陷被暴露出来。正如实际中所进行的，sysctl_intvec和proc_dointvec_minmax都总是与同一个ctl_table条目相关联的。因此，在调用处理例程（handler routine）proc_dointvec_minmax之前，任何超出允许范围之外的数值将会被策略例程sysctl_intvec截获。所以，我们知道——在给定内核里所有的ctl_tables最新定义的情况下——proc_dointvec_minmax将永远不会遇到超出界限的数值，而那里是唯一可以触发该缺陷的数值种类。某个调用程序或许可以注册一个使用proc_dointvec_minmax但没有策略例程的ctl_table，但是尽管这样，在proc_dointvec_ minmax里的这个缺陷迟早会造成一定损害。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">31193：返回0表示成功。这里不像在第31156行那样是一个错误，因为sysctl_intvec并不向table->data里写入。从用户空间读出的值只是被读进一个临时变量里作范围检查，然后就被删除；do_sysctl_strategy将完成那项工作，并只向table->data里进行写入。

我也说一句

发表

1万主题	49 听众	2万积分

TA的每日心情

	奋斗 2024-6-23 05:14

签到天数: 1043 天

[LV.10]以坛为家III

群组: 万里江山

群组: sas讨论小组

群组: C 语言讨论组

群组: Matlab讨论组

18^#

发表于 2005-3-4 22:31 |只看该作者 |招呼Ta 关注Ta

<H1 17pt 0cm 16.5pt; TEXT-ALIGN: center" align=center>第11章 可调内核参数</H1><

0cm 0cm 0pt">遵循Unix的BSD 4.4版本所倡导的风格，Linux提供sysctl系统调用以便在系统运行过程中对它所拥有的某些特性进行检查和重新配置，它并不需要你编辑内核的源代码、重新编译，然后重启机器。这是对早期Unix版本的一个十分重要的改进，在早期版本里调整系统经常是令人头痛的琐碎事务。Linux把可以被检查和重新配置的系统特性有机地组织成了几个种类：常规内核参数、虚拟内存参数、网络参数，等等。<

0cm 0cm 0pt">同样的特性也可以从一个不同的接口进行访问：/proc文件系统。（因为它真正的是系统的一个透视区（window）而不只是真实文件的一个容器，所以/proc是一个“伪的文件系统”，不过那是一个蹩脚的词汇，而且无论如何这个区别在此并不重要。）每种可调内核参数在/proc/sys下都表现为一个子目录，而每个单独的可调系统参数由某个子目录下的一个文件来代表。这些子目录可能又包含一级子目录，它们仍然含有更多的代表可调系统参数的文件和子目录，等等，但是这种嵌套级数从来都不会很深。 <

0cm 0cm 0pt">/proc/sys绕过了通常的sysctl接口：一个可调内核参数的值可以简单的通过读取相应的文件来得到，通过写入该文件可以设置它的值。普通Unix文件系统的许可被应用于这些文件，以便对能够对它们进行读写的用户进行控制。大多数文件对所有用户是可读的但是只对root（根用户）可写，不过也有例外：比如，/proc/sys/vm下的文件（虚拟内存参数）只能被root来读写。如果不使用/proc/sys，检查和调整系统将需要编写程序并使用必须的参数调用sysctl——虽然不是任务艰巨的劳动，可是也比不上使用/proc/sys来得方便。<

12pt 0cm 3.2pt">struct ctl_table<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">18274：这是本章涉及的代码中所使用的一个主要数据结构。struct ctl_tables通常是由数组聚合起来的，每个这样的数组对应于/proc/sys下某处一个单独目录里的条目。（依我之见，称它为struct ctl_table_entry可能更好。）root_table（30328行）以及在它之后的数组通过struct ctl_table的child指针连结节点而形成了一个数组树（child将在下边的列表中介绍）。注意所有这些都是ctl_table的数组，它只是为struct ctl_table进行typedef；18184行完成这项工作。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> 图11.1示意出了数组树间的关系。这幅图显示了由root_table形成的树的一小部分以及它所指向的树。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> struct ctl_table具有如下成员：<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l0 level1 lfo1; tab-stops: list 57.25pt">l ctl_name——是唯一标识表项的一个整数——在它所在的数组中是唯一的；这个数字在不同的数组中是可以重用的。数组的任何一项都已经存在这样一个唯一的数字了——就是它的数组下标——可是这个数字不能被用于该目的，因为我们想要维护不同内核发布版本中的二进制兼容性。与某内核版本里一个数组项相关联的可调内核参数可能不会出现在将来的内核版本里，所以假如参数是被它们的数组下标定义的，对数组里废弃项目位置的重新使用将使还没有在新内核版本下编译过的程序变得混乱。随着时间的推移，为了向后兼容而带上的只浪费空间但没有作用的元素项将会使数组变得乱七八糟。相反的，这种方法只会“浪费”整数，而整数资源却无疑是非常丰富的。（另一方面，查找也会更慢，因为一个简单的数组下标还不足以满足这种方法。）<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: 0cm">要注意的是这与有系统调用的情形相当类似：每个系统调用都与一个在系统调用表里唯一标识它位置的数字相关联。但是在这种情况里使用了一个不同的解决办法，可能由于速度在此并不重要的缘故。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> <

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"><wrapblock><v:shapetype><v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path connecttype="rect" gradientshapeok="t" extrusionok="f"></v:path><lock aspectratio="t" v:ext="edit"></lock></v:shapetype><v:shape><v:imagedata></v:imagedata><w:wrap type="topAndBottom"></w:wrap></v:shape></wrapblock> <

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt; TEXT-ALIGN: center" align=center>图11.1 ctl_table 树的一部分<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> <

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> struct ctl_table具有如下成员：<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l0 level1 lfo1; tab-stops: list 57.25pt">l procname——是用于/proc/sys下的相应项的一个可供我们阅读的简短文件名。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l0 level1 lfo1; tab-stops: list 57.25pt">l data——一个指向与此表项关联的数据的指针。它通常指向一个int或者一个char（当然，指向char的指针是字符串）。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l0 level1 lfo1; tab-stops: list 57.25pt">l maxlen——可以读取或者写入data的最大字节数。如果data指向一个单精度型的int，举例来说，maxlen就应该是sizeof（int）。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l0 level1 lfo1; tab-stops: list 57.25pt">l mode——Unix类型的文件许可位，它对应于这一项的/proc文件（或目录）。对此的解释需要少量文件系统的内容。就像其它Unix的实现一样，Linux使用三个三元组，其中每一位都记录一个文件许可（在ls -l命令产生的列表里它们表现为r、w，和x的三组字母）——参见图11.2。它们占据mode的低端9位。文件系统把文件的mode里剩余的位留作它用，比如用来跟踪是否文件是常规文件（第16位，当它如此时）、目录（第15位）、setuid或setgid执行程序（第12和11位），等等。不过就本章的目的来说，那些其它位都不是我们所关心的内容。<

0cm 0cm 0pt"><wrapblock><v:shape><v:imagedata></v:imagedata><w:wrap type="topAndBottom"></w:wrap></v:shape></wrapblock> <

0cm 0cm 0pt; TEXT-INDENT: 0cm"> <

0cm 0cm 0pt; TEXT-INDENT: 0cm; TEXT-ALIGN: center" align=center>图11.2 文件的mode位<

0cm 0cm 0pt; TEXT-INDENT: 0cm"> <

0cm 0cm 0pt 57.25pt; TEXT-INDENT: 0cm">这种方式的结果是，读者将经常见到八进制的常数004、002，和001与mode一起使用——它们分别是在移位mode后可能得到的适当的三位组中检测读（r）、写（w），和执行（x）位。这种移位和检查工作基本上是在30544行的test_perm里完成的。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: 0cm">注意如果一个表项的maxlen是0，那么不管它的mode是什么，从最终效果上看它都是既不可读也不可写的。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l0 level1 lfo1; tab-stops: list 57.25pt">l child——如果这是一个目录类型的条目，那么它就是指向子表（child table）的一个指针。在这样的情况下，因为没有数据与此条目相关联，data将是NULL，而maxlen则将是0。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l0 level1 lfo1; tab-stops: list 57.25pt">l proc_handler——指针，指向对data成员实际进行读取和写入操作的一个函数；它在通过/proc文件系统读写数据时被使用。以这种方法，任何类型的数据都可以通过data来进行指向，而且proc_handler函数会正确的处理对它的工作。

roc_handler通常指向proc_dostring函数（30820行）或proc_dointvec函数（30881行）；这两个以及其它被普遍适用的函数将在本章后面被讨论。（当然，任何具有适当原型（prototype）的函数都可以使用。）对于目录类型的条目，proc_ handler是NULL。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l0 level1 lfo1; tab-stops: list 57.25pt">l strategy——指针，指向对data成员实际进行读取和写入操作的另一个函数；它使用在通过sysctl系统调用进行读写的时候。它通常是sysctl_string（31121行），不过也可以是stringctl_intvec（31163行）；这两个函数在本章后面进行讨论。出于种种原因，大多数可调内核参数是通过/proc接口而不是sysctl系统调用进行调整的，所以这个指针是NULL会比非空更为常见。l de——指向struct proc_dir_entry的一个指针，它在/proc文件系统代码中使用以追踪文件系统里的文件或目录。如果它非空，struct ctl_table就在/proc下的某处注册过了。l extra和extra2——指向在处理这个表元素时所需的任何补充数据。它们当前只用于指定某些整数参数的最小和最大值。<H2 13pt 0cm">/proc/sys 支持</H2>不是所有实现用于可调内核参数/proc/sys接口的代码都包括在这本书中——的确，大部分代码并没有包括在内，因为它们基本上属于/proc文件系统本身。尽管如此，只要你不关心/proc剩下的部分是如何工作的，就不难理解在kernel/sysctl.c里的代码，它们与/proc文件系统一起工作用来使/proc下的可调内核参数是可见的。register_proc_table30689：register_proc_table函数在/proc/sys下注册一个ctl_table。注意这里并不要求所提供的表是根一级的节点（即ctl_table没有双亲）——它本应该是，不过这取决于调用者是否能够进行保证。 这个表被直接建立在root之下，它应该对应于/proc/sys或者其下的一个子目录。（在初次调用时，root总是指向proc_sys_root的，但是在递归调用时它的值改变了。）30696：开始在table数组的所有元素中进行循环；在当前元素的clt_name成员为0时循环结束，表示这是数组的末尾。30698：如果ctl_table的procname元素是NULL，那么即使同一数组的其它元素都可以为用户所见，它也不可以在/proc/sys下被用户所见。这样的数组元素会被跳过。30701：如果表项有procname，表明它应该在/proc/sys下被注册，那么它一定还有一个proc _handler（如果是一个叶子，或文件类型的节点）或者一个child（如果是一个目录类型的节点）。如果它同时缺少这两者，那么系统将显示一条警告，而后循环继续进行。30711：若表项有一个proc_handler，它被标记成常规文件。30713：否则，正如可从第30701行推断的那样，它一定有一个非空的child，这样该条目将被看作是一个目录。注意并没有禁止ctl_table同时拥有非空proc_handler和child这两者——在这种情形下，所有代码将对其一视同仁。30715：用给定的名字搜索一个存在的子目录，如果找到就让de指向它，如果没找到则de为NULL。为什么对文件不做类似的检查比较难于理解——这可能是我没有领会的文件系统的某个细节问题，答案无疑就在那里。30723：如果指定的子目录已经不存在了，或者假如table对应于一个文件而不是一个目录，新的文件或者目录就会通过调用create_proc_entry（未包含在本书中）来创建。30728：如果表项是一个叶子节点，register_proc_table会告诉文件系统代码使用由proc_sys_ inode_operations（30295行）定义的文件操作。proc_sys_inode_operations只定义了两个操作，读和写（不是搜索、内存映射，或者其它）。这些操作是用proc_readsys和proc_writesys函数（30802和30808行）来执行的，在本章的后面章节中将对它们进行介绍。30731：到了这一行，de就不可能是NULL了——它或者已经非空或者在第30723行被初始化了。30733：如果增加的条目是目录类型，register_proc_table会被递归调用来增加这一项的所有子孙。这是内核里不多见的一次递归调用。unregister_proc_table30739：unregister_proc_table函数删除ctl_table数组树和/proc文件系统之间的关联。ctl_ table里的条目以及它们下面所有的“子目录”里的条目也将会从/proc/sys消失。30743：同第30396行一样，这一行开始在给定的表项数组上进行循环。30744：与/proc/sys下任意条目都不关联的表项具有一个为NULL的de成员；显然这些表项可被忽略。30748：如果/proc文件系统认为这是一个目录，但表项是一个叶子（非目录），这两个结构就是不一致的。unregister_proc_table就会显示一条警告并继续循环，而不会移去这一项。30752：目录被逐层的进行释放——内核中另一次并不多见的递归过程。30756：在递归调用结束之后，unregister_proc_table检查是否所有子目录和文件都被逐层删除了——如果不是，当前元素就不能被安全的移去，接着要继续循环。30762：这里就是为什么子目录（以及其中的文件）可能还没有被移去的原因：它们可能当前还正被使用着。如果这个元素正在被使用，循环将继续，这样该元素就不会被移走。30765：节点通过proc_unregister（本书不进行介绍）从文件系统里被删除，接着用于追踪该节点而分配的内存被释放。do_rw_proc30771：do_rw_proc实现proc_readsys（30802行）和proc_writesys（30806行）函数的核心部分，这两个函数被/proc文件系统代码用于对ctl_table执行读取和写入操作。30782：确保一个表与/proc/sys下的这一条目相关联。30785：注意这一行的第一个测试与第30782行的第二个测试是相重复的，这是因为table是从de->data初始而来。30788：确保调用进程有适当的读或写权限。30795：调用该表项的proc_handler来完成真正的读操作或写操作。（要注意第30785行证实了proc_ handler成员是非空的。）如前所述，proc_handler成员通常是proc_dostring或proc_ dointvec（30820行和30792行），在随后的几段中我们将对它们进行讨论。30799：do_rw_proc返回实际读取或写入的字节数。注意到本地变量res完全是多余的；它可以被参数count所替代。proc_dostring30820：proc_dostring是供文件系统代码调用以对C语言字符串型的内核参数进行读取或写入操作的函数。 注意write标志表示调用者正在写表元素，不过这主要是涉及从输入缓冲区里进行读取——因此，用来写入的代码是受读控制的。类似的，如果write未被设置，调用者正从该表项读取，这里主要涉及的是写入给定的缓冲区。 这个函数在第31085行还实现了一个存根程序（stub）；这个存根程序在/proc文件系统被编译出内核时使用。大多数其它函数中的类似存根程序将在这个存根程序之后被介绍。30835：从输入缓冲区内读取字符直到一个表示结束的ASCII NUL（0）字节或者发现新的一行，再或者到达了被允许从该输入缓冲区内读出数据的最大值（被lenp所指定）为止。（为了不引起混淆，牢记NULL是一个C指针常量，而NUL——只有一个L——是ASCII用于字符数字0的术语。）30842：如果从缓冲区读出的字符数超出了可在表项里存储的限度，该数目会被降低。在循环之前就限制最大输入长度（lenp）可能会更高效，因为不管怎样从buffer里读取大于table->maxlen字节的数据是无意义的。实际上，循环可能读出，假设是1024字节，然后降低计数到64，因为表项里只能存储这么多。30844：该字符串从输入缓冲区里被读出，然后以NUL结束。30847：内核为每个进程所拥有的每个文件维护一个“当前位置”变量；这就是struct file的f_pos成员。它是tell系统调用返回的值并由seek系统调用进行设置。因此，文件的当前位置是由写入的字节数所推进的。proc_doutsstring30871：在获得uts_sem信号量后（29975行），proc_doutsstring仅是调用proc_dostring。这个函数被kern_table（30341行）里的一些条目用来设置system_utsname结构体的不同部分（20094行）。do_proc_dointvec30881：proc_dointvec（30972行）把它的工作委托给了该函数。do_proc_dointvec读或写一个被table的data成员所指向的int类型数组。要读写的int类型数目通过lenp传递；它通常是1，所以本函数通常只被用于读写单独一个int。 用于int的值是被buffer指定的。这些int是不会被以一个未经加工的int数组传递的；相反的，它们以ASCII文本给出，而这正是用户写入相关/proc文件的。30898：在所有要读写的int中循环。left追踪调用者想要读写int的剩余数目，而vleft追踪table->data里剩余的有效元素数目。在这二者中任何一个到达0，或它从半途退出时，该循环结束。 注意如果从循环中去掉第30899行的if语句，可以使整个循环的效率稍微提高一些，尽管这样做的结果较难维护。取代的代码如下： P556—1 这种方式使得并不在循环内改变的write的值将只需被检查一次，而不必在每次循环重复检查。30900：向前搜索一个不是空格的字符，它是输入（缓冲区）里下一个数字的开头。30913：从用户空间把一大块数据复制到本地缓冲区buf，然后以NUL结束buf。现在buf里包含了所有输入缓冲里剩余的ASCII文本——或者是它所能容纳的那些文本。 这种方法看起来不很有效率，原因在于它可能读取的超出了它所需要的。然而，因为buf的容量仅为20（TMPBUFLEN，30885行），它就不可能读取比它所需多出许多的数据。这里的思想可能是读入稍多一些数据要比检查每个字节以确定是否应该停止读操作所付出的代价要少些。 计划使buf足够大来包括任何64位整数的ASCII表示，以便这个函数不仅可以支持32位平台还可以支持64位平台。的确，它只能满足最大的正64位整数，它有19个数位（使终结的NUL字节是第20个字节）。可是要记住这些是有符号的整数，所以最小的64位有符号整数，即-9,223,372,032,854,775,808也应是合法输入。这个数字无法被正确的读取。但是幸运的是，补救方法工作量不大而且也非常明显。 随后读者就能够看到当这个输入出现时代码将如何对其进行处理。30919：处理打头的减号（-），如果发现一个减号就跳过它并设置一个标志。30923：确保从buffer读取的文本（可能是打头的减号之后的部分）至少是以一个数字开始的，这样它才能顺利的转换为一个整数。若没有这次检查，就不可能分辨出第30925行调用simple_strtoul返回的0是因为输入就是“0”还是因为函数无法转换任何文本。30925：把文本转换为一个整数，用conv参数换算结果。这个换算步骤对于proc_dointvec _jiffies这样的函数（31077行）比较有用，它用乘以常数HZ的简单手段把它的输入从秒转换为一段时间值（jiffies）。然而一般情况里，这个比例因子是1——即没有换算。30927：如果还要从缓冲区读取更多的文本，而且下一个要读的字符不是分割参数的（argument-separating）空格，那么整个参数（argument）就无法装进buf。这样的输入是无效的，所以循环提早结束。（一种可以导致函数处于这种状态的方式就是前边所描述的，输入表示的是最小的有符号64位整数。）不过，没有错误代码会被返回，因此调用者可能会错误地认为一切正常。当然这也不完全正确：一个错误代码将在第31070行被返回，不过这仅当无效参数是在第一次循环重复中被检测到的时候；如果它在后续的循环里被检测到，错误就不会被注意到。30929：参数被成功的读取。如果有前导的减号，那么现在就对它进行考虑，其它的本地变量被调整转移到下一个参数上，然后这个参数通过指针i被存储在表项中。30936：调用者从表项里读取值——由于无需对ASCII文本进行语法分析，这就是一种更为简单的情形。输出是由tab（制表符）分隔的，所以在除了第一次之外的任何一次循环里都把一个tab写入临时缓冲区里（在最后一个参数之后也不用写，只需在参数之间即可）。30938：接着，当前的整数被conv因子按比例缩减并打印到临时缓冲区里。这段代码同样会受读者前边已经见到的问题的损害：临时缓冲区buf的大小可能不足以容纳打印到它里边的全部整数值。在这种情况下，实际问题还会因缓冲区的第一个位置可以是一个tab制表符而被恶化。这会使buf的可用部分减少一个字符，进一步还会降低可被正确处理的输入范围。 在这里过大或过小的整数所造成的结果要比在写入情形里严重的多。在那种情形中，代码只要抛弃一些本应接受的输入即可。而在这儿，sprintf会越过buf的末尾继续写下去。 然而令人惊讶的是，这正是实际工作中可能发生的。在一次典型的执行过程中将有可能发生如下执行过程：从总体上来说，超过buf的末尾之后还要写入两个额外的字节（一个是因为它可以写入比预期更长的数字，另一个是tab制表符）。在栈里p通常是紧跟在buf之后的，所以超出buf末尾写入的部分将会覆盖p。可是由于p没有先被重新初始化时它是不会再被使用的，因此暂时覆盖它的值并没有危害。 这是一个看似有趣的事故，但是仅仅通过使buf稍微大一些就能够成为一个更好的解决方式，这样便于代码为正确的而不是错误的前提（reason）而工作。依照原样，对于gcc的代码生成器进行完全合法的很小的修改就能够揭示出潜在的缺陷。30939：把当前int的文本型表示复制进输出缓冲区里——或者和它所能容纳的相等的文本——接着更新本地变量使其转移到表项的下一个数组元素。30949：如果调用者刚才在读取，输出就被新的一行结束。if条件语句也保证循环不会在其第一遍执行而且还有空间来写入新行时就结束。注意输出缓冲区不是用ASCII NUL字节（读者可能会这样猜测）来结束的，因为它无需如此：调用者能够利用lenp被写入新值来减少返回字符串的长度。30954：如果调用者正向表项里写入数值，则略过从输入缓冲区读取的最后参数之后所有的空格。30967：更新文件的当前位置和lenp，然后返回0表示成功。proc_dointvec_minmax30978：proc_dointvec_minmax函数类似于do_proc_dointvec，区别是这个函数还把表项的extra1和extra2成员作为可以写入该表项的限制值数组来处理。extra1里的值是最小限度，而extra2里的值则是最大限度。另一点区别是proc_dointvec_minmax不使用conv参数。 因为这两个函数颇为相似，所以这一段里只介绍其不同之处。31033：最大的区别在于：当写入时，超过被min和max（在extra1和extra2数组上循环得到）所定义的范围之外的值将悄无声息的被略过。这段代码的目的明显是要使min和max伴随着val一起继续。当一个数值从输入缓冲里被读取时，它应该被下一个min和max来检查，然后才能决定被接受或被忽略。可是，这并非是实际所发生的那样。 假设从buffer而来的当前值已经进行了语法分析并存入里val，它小于最小值；为了更具体一些，再假设已是第三遍循环，以便min和max分别指向对应数组中的第三个元素。然后val将用min来检查并发现它超出了范围（太小），接着循环还要继续。可是min会作为检查的副作用被更新，而max则没有。现在，min指向它对应数组的第四个元素了，可是max仍然指向它的数组的第三个元素。这两者不再同步，而且它们还将保存这种状态，这样在下一个从buffer里读取的值被检验时采用的就是错误的界限。下列代码是最简单的一种修补程序： P558—1 正如读者将要在本章后边看到的，现在的Linux源代码永远不会暴露出这个缺陷。（未来发行的版本情况将有所不同，尽管还未曾明确写出。）<H2 13pt 0cm">sysctl系统调用</H2>用于可调内核参数的另一个接口是sysctl系统调用，以及相关函数。我不很喜欢这个接口。为什么不呢？对于大部分实际工作目的来说，使用sysctl——不过这种方法比修改源代码的旧方法来调整内核能够获得更大的性能提高——只会比访问/proc文件更为笨拙。通过sysctl来进行读写需要C程序（或相似的东西），而/proc却很容易通过外壳（shell）命令（或等价的通过命令解释程序脚本）来进行访问。另一方面，如果你正在C环境下工作，调用sysctl就比打开文件、读取并/或写入，以及再关闭它要方便的多，所以sysctl在今后也有它的用武之地。与此同时，还是让我们来看一看它的实现吧。do_sysctl30471：do_sysctl实现sys_sysctl（30504行），即sysctl系统调用的主要内容。注意sys_sysctl还在第31275行出现过——那个版本只是在sysctl系统调用被编译出内核时所使用的一个简单的存根程序（stub）函数。 如果oldval非空就用oldval返回内核参数原有的值，而它的新值在newval非空时从newval来进行设置。oldlenp和newlen分别标识出有多少字节应被写入oldval和从newval读出，这是在相应的指针不是NULL的时候；当指针为NULL的时候，它们将被忽略。 要注意这里的不对称性：函数对旧值的长度使用指针，而对新的长度不使用指针。这是因为旧的长度既是输入参数也是输出参数；它的输入值是可以通过oldval返回的最大字节数，而它的输出值是实际返回的字节数。与之相反，新的长度只是一个输入参数。30482：如果调用者需要旧的内核参数值，从oldlenp来对old_len进行设置。30490：开始遍历表树的循环列表。（参见本章随后对register_sysctl_table的讨论。）30493：使用parse_table（30560行，在下一段里讨论）来定位可调内核参数，然后读和/或写它的值。30495：如果parse_table分配了所有环境信息，它就被释放。很难准确地说出这个环境信息表示着什么。它不被本书所讨论的任何代码使用——据我所知，它目前甚至没有被内核里的任何代码所使用。30497：ENOTDIR错误表示没有在这一棵表树中找到指定的内核参数——它可能在另一棵还没有查找过的表树中。否则，error将为某个其它的错误代码，或者是代表成功的0；无论如何，函数应该返回了。30499：用DLIST_NEXT宏（本书对此不做介绍）来增加循环控制变量的值（loop iterator）。30501：返回ENOTDIR错误，报告出指定的内核参数在任何一个表里都未找到。parse_table30560：parse_table用于在表树里查找一个条目，其方法类同于在一个目录树里解析出一个完全合格的文件名的方法。其思想如下：沿着一个int数组（数组name）进行查找，并在一个ctl_table数组里搜索每个int。当找到一个匹配项时，它对应的子孙表就被递归查阅（如果匹配项是目录类型的条目），或者该条目被读和/或写（如果它是文件类型的条目）。30566：多少有些令人惊讶的是，这一行就开始了对整型数组name内所有元素的循环。习惯上的方法原本是把从这一行到第30597行所有代码用一个for循环包括起来，它的开始是这样的： for ( ; nlen ; ++name , --nlen , table = table -> child ) （这个循环还需要删除第30567和30568行代码，并用一个语句来替代从30587直到30590行的代码。）推测起来，可能是实际使用的版本可以生成更好的目标代码吧。30570：开始循环所有的表项，查找与当前name匹配的一项；当表已被遍历结束（table->ctl_ name为0了）或者指定的表项已被找到并处理时本循环结束。30572：把name数组的当前项读入n里，以便它可以与当前表项的ctl_name进行检查。因为name在内层循环中没有变化，这个读取操作可以放在循环外边（也就是移至30569行）以提高一点速度。30574：核查是否当前ctl_table的名字与被找到的名字相匹配，或是否它有特殊的“通配符（wildcard）”值，即CTL_ANY（17761行）。后者的使用目的还不清楚，因为现在并没有内核源代码的任何一处使用过CTL_ANY。它可能用于将来的方案中——我也不认为它是过去版本的一个遗留物，因为CTL_ANY在2.0内核里也没有被用到，而且整个sysctl接口也只向后兼容到2.0以前的开发树版本。30576：如果这个表元素有一个孩子，它就是一个“目录”。30577：遵循标准Unix行为，检查目录的x（可执行）位来判断是否当前进程可被允许对它进行访问。注意到这与文件系统所实现的工作非常类似，虽然这并不是（/proc）文件系统接口。这样可以使这两种接口在施用于可调内核参数时能够得到一致的结果——如果一个用户有通过一种接口来修改某个内核参数的权限而通过另一种却没有该权限，那么将是非常不可思议的。30579：如果表项有一个策略（strategy）函数，它可能需要覆盖允许该进程进入目录的授权。这个策略函数将被访问，如果它返回一个非零值，整个查找就被中止。30587：进入目录。本行有效的继续外层循环，并转移到该名字的下一部分。30592：这个表节点是一个叶子节点，因此内核参数就被找到了。注意这并不打扰对name数组是否已到其最后元素的检查（也就是现在nlen是否为1），虽然可以证明如果不是那样就会有某类型错误产生。不管哪一种情况，do_sysctl_strategy（30603行）都要负责对当前表元素进行读和/或写操作。30598：name数组非空，可是它的元素在叶子节点被找到之前均已用完。parse_table就返回ENOTDIR错误，来表示查找指定节点失败。顺便提及一点，注意前一行里的分号是多余的。do_sysctl_strategy30603：do_sysctl_strategy在单独一个ctl_table里读和/或写数据。计划使用该表元素里的strategy成员，如果存在的话，来完成读/写工作。如果表元素没有它自己的strategy例程，某些通用的读/写代码将被替代使用。不过读者将要看到，它并不完全按照计划工作。30610：如果oldval非空，调用者将读取旧值，这样r位就会在op里被设置。类似的，如果newval非空则w位被设置。接着，第30614行核查许可，如果当前进程缺少所需的授权就返回EPERM错误。30617：如果表项有它自己的strategy例程，这个例程就要处理读/写请求。如果它返回负数——一个错误——这个错误就被传送给调用者。如果返回的是正数，0（成功）就会被传送给调用者。如果是0，strategy例程就拒绝由它自己来处理请求，取而代之的将是缺省行为。（读者可以设想只返回0的strategy例程，如果它完成一些其它诸如收集被调用次数的统计数据这样的工作，它仍然是有用处的。）30630：这里是通用读取代码开始的地方。注意get_user（13254行）的返回值不被检查。（类似的缺陷发生在第9537和31186行。）30632：确保不会有多于与该表项的maxlen成员所指定的数值相等的数据被返回。30634：通过oldval从表里复制所要求的数据，再将真正被写的数据总量存储在oldlenp中。30642：类似于oldlenp，要确保写入表项的数据不能多于它的maxlen成员所允许的值。注意如果copy_from_user在中途的第30644行检测到一个错误，tabel->data可能会在仅仅被部分更新的情况下就结束。30648：返回0表示成功。以下三种情况都可以达到这一点：l 调用者对这个表项既不读也不写。l 调用者尝试读和/或写这个表项，而且所有步骤都被成功执行。l 表项没有关联的数据，或者因为它的maxlen是0，所以它是只读的。三种情形中的第一种有点儿奇怪，而最后一种则更令人奇怪。第一种情况有些奇特是因为调用sysctl却要求它对指定的表项既不读也不写，这并没有多少意义，所以可以正当的把它当作一个错误来处理。尽管如此，它要与其它系统调用的内核实现保持基本一致，那就是把一个无操作请求不看作是一个错误。比如说，在第8章中介绍的sys_brk（33155行）在由调用者指定的新brk值与旧值相同时并不产生一个错误信号。第三种情况要比第一种奇怪一些，因为它可能真的反映着一个错误。例如，调用代码尝试写入一个maxlen是0的参数，而且由于系统调用返回成功值而认为该尝试已被完成。看起来事情好像不是这样，因为不管怎样为0的maxlen都会使该条目失效，不过还真的存在一个maxlen为0的表项——参见第30380行。最终，一切都归结为sysctl是怎样在文档中描述的，但是man帮助程序中却对此没有任何记载。我仍然认为do_sysctl_strategy在这种情况下应该返回一个EPERM错误。register_sysctl_table30651：把一个新的根已经被给出的ctl_table树插入到其它树所形成的循环链表里。30655：分配一个struct ctl_table_header用来管理新树的信息。30659：把新的首部（跟踪ctl_tables数组形成的新树）插入到首部组成的链表里。 30666：调用register_proc_table（30689行，本章前边讨论过）把新的表树注册在/proc/sys目录下。如果没有内核在没有/proc文件系统支持的情况下进行编译时，则这一行将被编译到内核以外。30688：新分配的首部被返回给调用程序，以便调用程序能够在以后通过把该首部转递给unregister_sysctl_table（30672行）来删除相应的树。unregister_sysctl_table30672：如前所述，这个简单函数只是把一个ctl_table的树从内核里这样的树所组成的循环链表里删除。如果内核是在支持/proc的情况下编译的，它也用于从/proc文件系统里删除相应的数据。 回顾一下第30490和30500行，读者不难发现root_table_header（30256行）——对应于root_table的列表节点——是在遍历树的循环链表时被用作头和尾节点的。读者现在能够明白实际上在unregister_sysctl_table函数里没有什么可以避免root_table_header被从表头列表里删除——它只是还没有这样做而已。sysctl_string31121：sysctl_string是ctl_table的策略例程之一。回忆一下，策略例程可以从第30618行（在do_sysctl_strategy里）被调用来有选择的覆盖一个表项的缺省读/写代码。（策略例程也可以从第30580行被调用，不过该例程却从不会被调用。）31127：如果该表没有相关数据，或者如果可访问部分的长度是0，则返回ENOTDIR错误。这与do_sysctl_strategy的做法是不一致的，在同样的情况里它返回的是成功。31138：当前字符串的值被复制到用户空间，然后结果以NUL来结束（这意味着比由lenp指定值多一个字节的数据可能会被复制——依据文档记录，这可能是一个缺陷）。因为当前值已经是NUL结束的，这四行代码可以被简化为两行： if ( copy_to_user ( oldval , table -> data , len + 1 ) ) return –EFAULT ; 这种改变的正确性部分上依赖于当写入table->data时代码剩余部分所遵循的三个特征：l 代码剩余部分不能把多于table->maxlen的char数据复制进table->data里。（这也使得第31136行的测试变得没有必要。即使还需要该测试，那也只用检查>，而不用检查>=了。）l 然后table->data以NUL来结束，如果必要就复写最后一个拷贝进来的字节，以便包括NUL在内的总长度不大于table->maxlen。l table->maxlen永不发生变化。 因为所有三个特征都有效，所以在第31138行len将总是严格小于table->maxlen，而且结束NUL字节一定会在table->data[len+1]或之前的位置出现。

我也说一句

发表

1万主题	49 听众	2万积分

TA的每日心情

	奋斗 2024-6-23 05:14

签到天数: 1043 天

[LV.10]以坛为家III

群组: 万里江山

群组: sas讨论小组

群组: C 语言讨论组

群组: Matlab讨论组

17^#

发表于 2005-3-4 22:29 |只看该作者 |招呼Ta 关注Ta

12pt 0cm 3.2pt">send_IPI_single<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">4937： send_IPI_single函数发送一个IPI——那是Intel对处理器间中断（interprocessor interrupt）的称呼——给指定的目的CPU。在这一行，内核以相当低级的方式与发送CPU的本地APIC对话。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">4949： 得到中断命令寄存器（ICR）高半段的内容——本地APIC就是通过这个寄存器进行编程的——不过它的目的信息段要被设置为dest。尽管__prepare_ICR2（4885行）里使用了“2”，CPU实际上只有一个ICR而不是两个。但是它是一个64位寄存器，内核更愿意把它看作是两个32位寄存器——在内核代码里，“ICR”表示这个寄存器的低端32位，所以“ICR2”就表示高端32位。我们想要设置的的目的信息段就在高端32位，即ICR2里。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">4950： 把修改过的信息写回ICR。现在ICR知道了目的CPU。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">4953： 调用__prepare_ICR（4874行）来设置我们想要发送给目的CPU的中断向量。（注意没有什么措施能够保证目的CPU不是当前CPU——ICR完全能够发送一个IPI给它自己的CPU。尽管这样，我还是没有找到有任何理由要这样做。）<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">4957： 通过往ICR里写入新的配置来发送中断。<H2 13pt 0cm">SMP支持如何影响内核</H2><

0cm 0cm 0pt">既然读者已经学习了能够成功支持SMP的若干原语，那么就让我们来纵览一下内核的SMP支持吧。本章剩余的部分将局限于对分布在内核之中的那些具有代表性的SMP代码进行讨论。<H3 13pt 0cm">对调度的影响</H3><

0cm 0cm 0pt">schedule（26686行）正是内核的调度函数，它已在第7章中全面地介绍过了。schedule的SMP版本与UP的相比有两个主要区别：<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l2 level1 lfo1; tab-stops: list 42.25pt">l 在schedule里从第26780开始的一段代码要计算某些其它地方所需的信息。<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l2 level1 lfo1; tab-stops: list 42.25pt">l 在SMP和UP上都要发生的对__schedule_tail的调用（26638行）实际上在UP上并无作用，因为__schedule_tail完全是为SMP所写的代码，所以从实用的角度来说它就是SMP所特有的。<

12pt 0cm 3.2pt">schedule<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26784：获取当前时间，也就是自从机器开机后时钟流逝的周期数。这很像是检查jiffies，不过是以CPU周期而不是以时钟滴答作为计时方法的——显然，这要精确得多。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26785：计算自从schedule上一次在此CPU上进行调度后过去了多长时间，并且为下一次的计算而记录下当前周期计数。（schedule_data是每个CPU aligned_data数组的一部分，它在26628行定义。）<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26790：进程的avg_slice成员（16342行）记录该进程在其生命周期里占有CPU的平均时间。可是这并不是简单的平均——它是加权平均，进程近期的活动远比很久以前的活动权值大。（因为真实计算机的计算是有穷的，“很久以前”的部分在足够远以后，将逐渐趋近于0。）这将在reschedule_idle中（26221行，下文讨论）被用来决定是否把进程调入另一个CPU中。因此，在UP的情况下它是无需而且也不会被计算的。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26797：记录哪一个CPU将运行next（它将在当前的CPU上被执行），并引发它的has_cpu标志位。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26803：如果上下文环境发生了切换，schedule记录失去CPU的进程——这将在下文的__schedule_tail中被使用到。<

12pt 0cm 3.2pt">__schedule_tail<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26654：如果失去CPU的任务已经改变了状态（这一点在前边的注释里解释过了），它将被标记以便今后的重新调度。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26664：因为内核已经调度出了这个进程，它就不再拥有CPU了——这样的事实也将被记录。<

12pt 0cm 3.2pt">reschedule_idle<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26221：当已经不在运行队列里的进程被唤醒时，wake_up_process将调用reschedule_idle，进程是作为p而被传递进reschedule_idle中的。这个函数试图把新近唤醒的进程在一个不同的CPU上进行调度——即一个空闲的CPU上。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26225：这个函数的第一部分在SMP和UP场合中都是适用的。它将使高优先级的进程得到占用CPU的机会，同时它也会为那些处于饥饿状态的进程争取同样的机会。如果该进程是实时的或者它的动态优先级确实比当前占有CPU进程的动态优先级要高某个量级（强制选定的），该进程就会被标记为重新调度以便它能够争取占用CPU。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26263：现在来到SMP部分，它仅仅适用于在上述测试中失败了的那些进程——虽然这种现象经常发生。reschedule_idle必须确定是否要在另一个CPU上尝试运行该进程。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> 正如在对schedule的讨论中所提到的那样，一个进程的avg_slice成员是它对CPU使用的加权平均值；因此，它说明了假如该进程继续运行的话是否它可能要控制CPU一段相对来说较长的时间。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26264：这个if条件判断的第二个子句使用related宏（就在本函数之上的第26218行）来测试是否CPU都在控制着——或想要控制——内核锁。如果是这样，那么不管它们生存于何处，都将不大可能同时运行，这样把进程发送到另一个CPU上将不会全面提高并行的效能。因此，假如这条子句或者前一条子句被满足，函数将不会考虑使进程在另一CPU上进行调度并简单的返回。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26267：否则，reschedule_idle_slow（接下来讨论）被调用以决定是否进程应当被删除。<

12pt 0cm 3.2pt">reschedule_idle_slow<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">26157：正如注释中所说明的，reschedule_idle_slow试图找出一个空闲CPU来贮存p。这个算法是基于如下观察结果的，即task数组的前n项是系统的空闲进程，机器的n个CPU中每个都对应一个这样的空闲进程。这些空闲进程当（且仅当）对应CPU上没有其它进程需要处理器时才会运行。如果可能，函数通常是用hlt指令使CPU进入低功耗的“睡眠”状态。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> 因此，如果有空闲CPU存在的话，对任务数组的前n个进程进行循环是找出一个空闲CPU所必须的。reschedule_idle_slow函数只需简单的查询每个空闲进程是否此刻正在运行着；如果是这样，它所在的CPU就一定是空闲的，这就为进程p提供了一个很好的候选地点来运行。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> 当然，这个被选中的明显空闲的CPU完全有可能只是暂时空闲而且必定会被一堆拥有更高优先级的，CPU绑定的进程所充满，这些进程可能在一纳秒后就会被唤醒并在该CPU上运行。所以，这并不是完美的解决方法，可是从统计的角度来说它已经相当好了——要记住，像这样的选择是很符合调度程序“快餐店式（quick-and-dirty）”的处理方式的。26180：建立本地变量。best_cpu是此时正在运行的CPU；它是“最佳”的CPU，因为p在其上会避免缓冲区溢出或其它的开销麻烦。this_cpu是运行reschedule_idle_slow的CPU。26182：idle和tsk将沿task数组进行遍历，target_tsk将是所找到的最后一个正在运行的空闲进程（或者假如没有空闲进程它就为NULL）。26183：i 从smp_num_cpus（前边被叫作n）开始并且在每一次循环后都递减。26189：假如这个空闲进程的has_cpu标志被设置，它就正在它的CPU上运行着（我们将称这样的CPU为“目标（target）CPU”）。如果该标志没有被设置，那么目标CPU就正被某个其它进程占用着；因而，它也就不是空闲的，这样reschedule_idle_slow将不会把p发送到那里。刚刚提及问题的反面在这里出现了：现在仅因为CPU不空闲并不能表示它所有的进程都不会死亡而使其空闲下来。可是reschedule_idle_slow无法知道这种情形，所以它最好还是假定目标CPU将要被占用一段时间。无论如何，这都是可能的，就算并非如此，某个其它的进程也将很快会被调度到另一个空闲CPU上运行。26190：不过假如CPU目标就是当前CPU，它就会被跳过。这看来很怪，不过无论怎样这都是“不可能发生”的情况：一个空闲进程的counter是负值，在第26226行的测试将早已阻止这个函数执行到这一步了。26192：找到一个可用的空闲CPU；相关的空闲进程被保存在target_tsk中。 既然已找到了空闲CPU，为什么现在不中断循环呢？这是因为继续循环可能会发现p当前所在的处理器也是空闲的，在两个CPU都空闲时，维持在当前处理器上运行要比把它送往另一个好一些。26193：这一步reschedule_idle_slow检查是否p所在的处理器空闲。如果刚才找到的空闲CPU就是p所在的，函数将向前跳转到send标记处（26203行）来在那个CPU上对p进行调度。26199：函数已经转向另一个CPU；它要递减。26204：如果循环遍历了所有空闲的CPU，该CPU的空闲任务就被标记为重新调度并且smp_ send_reschedule（26205行）会给那个CPU发送一个IPI以便它可以重新对其进程进行调度。 正如读者所见到的，reschedule_idle_slow是CPU之间协调无需在UP系统中所进行的工作的典范示例。对于UP机器来说，询问进程应占有哪一个CPU和询问它是否应拥有系统的唯一的一个CPU或根本不应该占有CPU是等价的。SMP机器必须花费一些代价来决定系统中哪一个CPU是该进程的最佳栖身之所。当然，换来的速度极大提高使得这些额外的努力还是相当合算的。release22951：release中非SMP特有的部分在第7章中已经介绍过了——在这里，一个僵进程（zombie）将被送往坟墓，而且其struct task_struct将被释放。22960：查看是否该进程拥有一个CPU。（拥有它的CPU可能还没有清除这个标志；但是它马上就将执行这个操作。）如果没有，release退出循环并像往常一样接着释放struct task_ struct结构体。22966：否则，release等待进程的has_cpu标志被清除。当它被清除后，release再次进行尝试。这种貌似奇特的情况——某进程正被删除，然而它仍占有CPU——确实少见，不过并非不可能。进程可能已经在一个CPU上被杀死，而且这个CPU还没来得及清除has_cpu标志，但是它的父进程已经正在从另一个CPU对它进行释放了。<H4 14pt 0cm 14.5pt">smp_local_timer_interrupt</H4>对于UP专有的update_process_times函数（27382行）来说，这个函数就是它在SMP上的对应。该函数能够完成update_process_times所完成的所有任务——更新进程和内核在CPU使用方面的统计值——以及其它的一些操作。与众不同的地方在于拥有这个特性的SMP版本并没有被添加到一个UP函数中去，而是采用了一个具有同样功能，但却完全分离的功能程序。在浏览了函数之后，我们就能够很容易的知道这是为什么了——它与UP版本差别甚大到以至于试图将二者融为一体都将是无意义的。smp_local_timer_interrupt可从两个地方进行调用：l 从smp_apic_timer_interrupt（5118行）调用，它用于SMP的时钟中断。这是通过使用在第1856行定义的BUILD_SMP_TIMER_INTERRUPT宏于第919行建立起来的。l 从第5776行通常的UP时钟中断函数里进行调用。只有当在UP机器上运行SMP内核时此种调用方式才会发生。smp_local_timer_interrupt5059： prof_counter（4610行）用于跟踪到更新进程和内核统计值之前内核应该等待多长时间；如果该计数器还没有到达0，控制流程会有效地跳转到函数的末尾。正如代码中所证明的，prof_counter项目从1开始递减计数，除非由根（root）来增加这个值，因此在缺省情况下每次时钟滴答都要完成此项工作。然后，prof_counter[cpu]从prof_multiplier[cpu]处被重新初始化。 明显的这是一个优化的过程：每次时钟滴答都在这个if语句块里完成所有工作将相当的缓慢，所以我们可能想到以牺牲一些精确度的代价将工作分批完成。因为乘法器是可调的，所以你可以指定你所需要的速度频率来放松对准确度的要求。 然而，关于这段代码我总感到有些困惑：确定无疑的是，当prof_multiplier[cpu]耗尽时，统计值应该被更新，就像prof_multiplier[cpu]的计数流逝一样——既然它们已经如此。（除了prof_multiplier[cpu]本身刚刚被改变时，不过这已经偏离了这里讨论的主题。）与此不同的是，这里代码表现出来的就好像只经过了一次滴答计数。或许其用意是为了以后能把记录下来的滴答数目和prof_multiplier[cpu]在某个地方相乘，不过现在并没有这样实现。5068： 当时钟中断被触发时假如系统正在用户模式运行，smp_local_timer_interrupt会假定全部滴答都是在用户模式里流逝的；否则，它将假定全部滴答是在系统模式里流逝的。5073： 用irq_enter（1792行）来夺取全局IRQ锁。这是我们要分批处理这项工作的另一个原因：并不需要在每次时钟滴答时都要得到全局IRQ锁，这有可能成为CPU之间争夺的一个重要根源，实际中函数是以较低的频度来争取该锁的。因此，函数不经常夺取这个锁，可是一旦它获得了锁，就不会再使其被锁。在此我们又一次以准确度的代价换来了这种效率上的提高。5074： 不用为保存空闲进程的统计值而操心。这样做只会浪费CPU的周期。总之，内核会跟踪系统处于空闲的总共时间，对空闲进程的更多细节进行统计价值不大（比如我们知道它们总是在系统模式下执行的，所以就没有必要再明确计算它们的系统时间了）。5075： update_process_times和smp_local_timer_interrupt在这一点上是一致的：它们都调用update_process_times来完成对单进程CPU使用统计的更新工作。5077： 减少进程的counter（它的动态优先级），如果它被耗尽就重新调度该进程。5082： 更新内核的统计数字。如在update_process_times中一样，用户时间既可以用内核的“最优时间”也可以用常规的用户时间来计算，这要取决于进程的优先级是否低于DEF_PRIORITY。5094： 重新初始化CPU的prof_counter并释放全局IRQ锁。该工作必须要以这种顺序完成，当然——若以相反的方式，则可能在prof_counter被重新初始化之前发生又一次时钟中断。<H4 14pt 0cm 14.5pt">lock_kernel和unlock_kernel</H4>这两个函数也有专门适应于x86平台的版本；但是在这里只介绍通用版本。lock_kernel10174：这个函数相当简单，它获得全局内核锁——在任何一对lock_kernel/unlock_kernel函数里至多可以有一个CPU。显然这在UP机器上是一个空操作（no-op）。10176：进程的lock_depth成员初始为–1（参见24040行）。在它小于0时（若小于0则恒为-1），进程不拥有内核锁；当大于或等于0时，进程得到内核锁。 这样，单个进程可以调用lock_kernel，然后在运行到unlock_kernel之前可能又将调用另一个要使用lock_kernel的函数。在这种情况中，进程将立刻被赋予内核锁——而这正是我们所期望的。 其结果是，一旦增加进程的lock_depth就会使lock_depth为0，那么进程以前就是没有锁的。所以，函数在此情形下获得kernel_flag自旋锁（3587行）。unlock_kernel10182：同样的，如果丢弃内核锁就会使lock_depth低于0值，进程退出它所进入的最后一对lock_kernel/unlock_kernel函数。此时，kernel_flag自旋锁一定要被解锁以便其它进程可以给内核加锁。通过测试结果的符号位（即使用“<0”而不是“== -1”）可以使gcc生成更高效的代码，除此之外，这还可能有利于内核在面对不配对的lock_ kernel/unlock_kernel时可正确执行（或者不能，这取决于具体情况）。<H4 14pt 0cm 14.5pt">softirq_trylock</H4>你可能能够回忆起在第6章的讨论中，softirq_trylock的作用是保证对于其它程序段来说下半部分代码（bottom half）是原子操作——也就是说，保证在任何特定时段的整个系统范围之内至多只有一个下半部分代码在运行。对于UP来说这相当容易：内核只不过需要检查或者还要设置一下标志位就可以了。不过对于SMP来说自然没有这样简单。softirq_trylock12528：测试并设置（tests-and-sets）global_bh_count的第0位。尽管读者可能会从global _bh_count的名字上得到另外一种看法，实际它总是0或者1的——这样的考虑是适当的，因为至多运行一个下半部分程序代码。不管怎样，如果global_bh_count已经是1了，那么就已经有一个下半部分代码在运行着，因此控制流程就跳转到函数末尾。12529：如果还可得到global_bh_lock，那么下半部分代码就能够在这个CPU上运行。这种情况与UP机器上使用的双锁系统非常类似。12533：softirq_trylock无法获取global_bh_lock，因此它的工作失败了。<H4 14pt 0cm 14.5pt">cli和sti</H4>正如在第6章中解释过的，cli和sti分别用于禁止和启用中断。对于UP这简化为单个cli或sti指令。而在SMP情况下，这就很不够了，我们不仅需要禁止本地CPU还要暂时避免其它CPU处理IRQ。因此对于SMP，宏就变成了对__global_cli和__global_sti函数的调用。__global_cli1220： 把CPU的EFLAGS寄存器复制到本地变量flags里。1221： x86系统里的中断使能标志在EFLAGS寄存器的第9位——在第1205行解释了EFLAG_IF_SHIFT的定义。它被用来检测是否已经禁止了中断，这样就不再需要去禁止它们了。1223： 禁止这个CPU的中断。1224： 如果该CPU没有正在对IRQ进行处理，__global_cli就调用get_irqlock（1184行）来获得全局IRQ锁。如果CPU已经在对IRQ进行处理了，那么正如我们马上要看到的，它已经拥有了该全局IRQ锁。 现在本CPU已经禁止了中断，而且它也拥有了全局IRQ锁，这样任务就完成了。__global_sti1233： 如果CPU没有正在对IRQ进行处理，__global_sti就在__global_cli中通过release_irqlock（10752行）调用来实现对全局IRQ锁的释放工作。如果CPU已经在对IRQ进行处理了，那么它已经拥有了该全局IRQ锁，正如在接下来的部分中将要解释的那样，这个锁将在其它地方被释放掉。 1235： 再次允许在本CPU上进行中断。<H4 14pt 0cm 14.5pt">irq_enter和irq_exit</H4>第6章中顺便提及了这两个函数的UP版本。包含在一对irq_enter/irq_exit之中的代码段都是原子操作，这不仅对于其它这样的代码区域是原子的，而且对于cli/sti宏对来说也是如此。irq_enter1794： 调用hardirq_enter（10761行）自动为本CPU增加全局IRQ计数和本地IRQ计数。这个函数记录了CPU正在处理一个IRQ的情况。1795： 执行循环直到这个CPU得到全局IRQ锁为止。这就是为什么我要在前面说明如果CPU正在处理IRQ，那么它就已经获得了全局IRQ锁的原因：到这个函数退出时，这两个特性都将被加强。对于内核代码来说，把这两个特性分离出去并没有太大的意义——它可以直接调用hardirq_enter，而且也不用去争夺全局IRQ锁。函数只是没有这样作而已。irq_exit1802：这个函数转向hardirq_enter的相反函数hardirq_exit（10767行）。顺便要提及的是，对irq_enter和irq_exit来说其irq参数都被忽略了——至少在x86平台上如此。

我也说一句

发表

1万主题	49 听众	2万积分

TA的每日心情

	奋斗 2024-6-23 05:14

签到天数: 1043 天

[LV.10]以坛为家III

群组: 万里江山

群组: sas讨论小组

群组: C 语言讨论组

群组: Matlab讨论组

16^#

发表于 2005-3-4 22:25 |只看该作者 |招呼Ta 关注Ta

<H1 17pt 0cm 16.5pt; TEXT-ALIGN: center" align=center>第10章 对称多处理（SMP）</H1><

0cm 0cm 0pt">在全书的讨论过程中，我一直在忽略SMP代码，而倾向于把注意力集中在只涉及一个处理器的相对简单的情况。现在已经到了重新访问读者已经熟悉的一些内容的时候了，不过要从一个新的角度来审视它：当内核必须支持多于一个CPU的机器时将发生什么？<

0cm 0cm 0pt">在一般情况下，使用多于一个CPU来完成工作被称为并行处理（parallel processing），它可以被想象成是一段频谱范围，分布式计算（distributed computing）在其中一端，而对称多处理（SMP—symmetric multiprocessing）在另一端。通常，当你沿着该频谱从分布式计算向SMP移动时，系统将变得更加紧密耦合——在CPU之间共享更多的资源——而且更加均匀。在一个典型的分布式系统中，每个CPU通常都至少拥有它自己的高速缓存和RAM。每个CPU还往往拥有自己的磁盘、图形子系统、声卡，监视器等等。<

0cm 0cm 0pt">在极端的情形下，分布式系统经常不外乎就是一组普通的计算机，虽然它们可能具有完全不同的体系结构，但是都共同工作在某个网络之上——它们甚至不需要在同一个LAN里。读者可能知道的一些有趣的分布式系统包括：Beowulf，它是对相当传统而又极其强大的分布式系统的一个通用术语称谓；SETI@home，它通过利用上百万台计算机来协助搜寻地外生命的证据，以及distributed.net，它是类似想法的另一个实现，它主要关注于地球上产生的密码的破解。<

0cm 0cm 0pt">SMP是并行处理的一个特殊情况，系统里所有CPU 都是相同的。举例来说，SMP就是你共同支配两块80486或两块

entium（具有相同的时钟速率）处理器，而不是一块80486和一块

entium，或者一块

entium和一块

owerPC。在通常的用法中，SMP也意味着所有CPU都是“在相同处境下的”——那就是它们都在同一个计算机里，通过特殊用途的硬件进行彼此通信。<

0cm 0cm 0pt">SMP系统通常是另一种平常的单一（single）计算机——只不过具有两个或更多的CPU。因此，SMP系统除了CPU以外每样东西只有一个——一块图形卡、一个声音卡，等等之类。诸如RAM和磁盘这样以及类似的资源都是为系统的CPU们所共享的。（尽管现在SMP系统中每个CPU都拥有自己的高存缓存的情况已经变得愈发普遍了。）<

0cm 0cm 0pt">分布式配置需要很少的或者甚至不需要来自内核的特殊支持；节点之间的协同是依靠用户空间的应用程序或者诸如网络子系统之类未经修改的内核组件来处理的。但是SMP在计算机系统内创建了一个不同的硬件配置，并由此需要特殊用途的内核支持。比如，内核必须确保CPU在访问它们的共享资源时要相互合作——这是一个读者在UP世界中所不曾遇到的问题。<

0cm 0cm 0pt">SMP的逐渐普及主要是因为通过SMP所获得的性能的提高要比购买几台独立的机器再把它们组合在一起更加便宜和简单，而且还因为它与等待下一代CPU面世相比要快的多。<

0cm 0cm 0pt">非对称多CPU的配置没有受到广泛支持，这是因为对称配置情况所需的硬件和软件支持通常较为简单。不过，内核代码中平台无关的部分实际上并不特别关心是否CPU是相同的——即，是否配置是真正对称的——尽管它也没有进行任何特殊处理以支持非对称配置。例如，在非对称多处理系统中，调度程序应该更愿意在较快的而不是较慢的CPU上运行进程，但是Linux内核没有对此进行区别。<

0cm 0cm 0pt">谚语说得好，“天下没有白吃的午餐”。对于SMP，为提高的性能所付出的代价就是内核复杂度的增加和协同开销的增加。CPU必须安排不互相干涉彼此的工作，但是它们又不能在这种协同上花费太多时间以至于它们显著地耗费额外的CPU能力。<

0cm 0cm 0pt">代码的SMP特定部分由于UP机器存在的缘故而被单独编译，所以仅仅因为有了SMP寄存器是不会使UP寄存器慢下来的。这满足两条久经考验的原理：“为普遍情况进行优化”（UP机器远比SMP机器普遍的多）以及“不为用不着的东西花钱”。<H2 13pt 0cm">并行程序设计概念及其原语</H2><

0cm 0cm 0pt"> 具有两个CPU的SMP配置可能是最简单的并行配置，但就算是这最简单的配置也揭开了未知问题的新领域——即使要两块相同的CPU在一起协调的工作，时常也都像赶着猫去放牧一样困难。幸运的是，至少30年前以来，就在这个项目上作了大量和非常熟悉的研究工作。（考虑到第一台电子数字计算机也只是在50年前建造的，那这就是一段令人惊讶的相当长的时间了。）在分析对SMP的支持是如何影响内核代码之前，对该支持所基于的若干理论性概念进行一番浏览将能够极大的简化这个问题。<

0cm 0cm 0pt">注意：并非所有这些信息都是针对SMP内核的。一些要讨论的问题甚至是由UP内核上的并行程序设计所引起的，既要支持中断也要处理进程之间的交互。因此即使你对SMP问题没有特别的兴趣，这部分的讨论也值得一看。<H3 13pt 0cm">原子操作</H3><

0cm 0cm 0pt">在一个并行的环境里，某些动作必须以一种基本的原子方式（atomically）执行——即不可中断。这种操作必须是不可分割的，就象是原子曾经被认为的那样。<

0cm 0cm 0pt">作为一个例子，考虑一下引用计数。如果你想要释放你所控制的一份共享资源并要了解是否还有其它（进程）仍在使用它，你就会减少对该共享资源的计数值并把该值与0进行对照测试。一个典型的动作顺序可能如下开始：<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l6 level1 lfo1; tab-stops: list 42.25pt">1. CPU把当前计数值（假设是2）装载进它的一个寄存器里。<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l6 level1 lfo1; tab-stops: list 42.25pt">2. CPU在它的寄存器里把这个值递减；现在它是1。<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l6 level1 lfo1; tab-stops: list 42.25pt">3. CPU把新值（1）写回内存里。<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l6 level1 lfo1; tab-stops: list 42.25pt">4. CPU推断出：因为该值是1，某个其它进程仍在使用着共享对象，所以它将不会释放该对象。<

0cm 0cm 0pt">对于UP，应不必在此考虑过多（除了某些情况）。但是对于SMP就是另一番景象了：如果另一个CPU碰巧同时也在作同样的事情应如何处理呢？最坏的情形可能是这样的：<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l3 level1 lfo2; tab-stops: list 42.25pt">1. CPU A把当前计数值（2）装载进它的一个寄存器里。<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l3 level1 lfo2; tab-stops: list 42.25pt">2. CPU B把当前计数值（2）装载进它的一个寄存器里。<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l3 level1 lfo2; tab-stops: list 42.25pt">3. CPU A在它的寄存器里把这个值递减；现在它是1。<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l3 level1 lfo2; tab-stops: list 42.25pt">4. CPU B在它的寄存器里把这个值递减；现在它是1。<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l3 level1 lfo2; tab-stops: list 42.25pt">5. CPU A把新值（1）写回内存里。<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l3 level1 lfo2; tab-stops: list 42.25pt">6. CPU B把新值（1）写回内存里。<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l3 level1 lfo2; tab-stops: list 42.25pt">7. CPU A推断出：因为该值是1，某个其它进程仍在使用着共享对象，所以它将不会释放该对象。8. CPU B推断出：因为该值是1，某个其它进程仍在使用着共享对象，所以它将不会释放该对象。内存里的引用计数值现在应该是0，然而它却是1。两个进程都去掉了它们对该共享对象的引用，但是没有一个能够释放它。这是一个有趣的失败，因为每个CPU都作了它所应该做的事情，尽管这样错误的结果还是发生了。当然这个问题就在于CPU没有协调它们的动作行为——右手不知道左手正在干什么。你会怎样试图在软件中解决这个问题呢？从任何一个CPU的观点来看待它——比如说是CPU A。需要通知CPU B它不应使用引用计数值，由于你想要递减该值，所以不管怎样你最好改变某些CPU B所能见到的信息——也就是更新共享内存位置。举例来说，你可以为此目的而开辟出某个内存位置，并且对此达成一致：若任何一个CPU正试图减少引用计数它就包含一个1，如果不是它就为0。使用方法如下：1. CPU A从特殊内存位置出取出该值把它装载进它的一个寄存器里。2. CPU A检查它的寄存器里的值并发现它是0（如果不是，它再次尝试，重复直到该寄存器为0为止。）3. CPU A把一个1写回特殊内存位置。4. CPU A访问受保护的引用计数值。5. CPU A把一个0写回特殊内存位置。糟糕，令人不安的熟悉情况又出现了。以下所发生的问题仍然无法避免：1. CPU A从特殊内存位置出取出该值把它装载进它的一个寄存器里。2. CPU B从特殊内存位置出取出该值把它装载进它的一个寄存器里。3. CPU A检查它的寄存器里的值并发现它是0。4. CPU B检查它的寄存器里的值并发现它是0。5. CPU A把一个1写回特殊内存位置。6. CPU B把一个1写回特殊内存位置。7. CPU A访问受保护的引用计数值。8. CPU B访问受保护的引用计数值。9. CPU A把一个0写回特殊内存位置。10. CPU B把一个0写回特殊内存位置。好吧，或许可以再使用一个特殊内存位置来保护被期望保护初始内存位置的那个特殊内存位置……。面对这一点吧：我们在劫难逃。这种方案只会使问题向后再退一层，而不可能解决它。最后，原子性不可能由软件单独保证——必须要有硬件的特殊帮助。在x86平台上，lock指令正好能够提供这种帮助。（准确地说，lock是一个前缀而非一个单独的指令，不过这种区别和我们的目的没有利害关系。）lock指令用于在随后的指令执行期间锁住内存总线——至少是对目的内存地址。因为x86可以在内存里直接减值，而无需明确的先把它读入一个寄存器中，这样对于执行一个减值原子操作来说就是万事俱备了：lock内存总线然后立刻对该内存位置执行decl操作。函数atomic_dec（10241行）正好为x86平台完成这样的工作。LOCK宏的SMP版本在第10192行定义并扩展成lock指令。（在随后的两行定义的UP版本完全就是空的——单CPU不需要保护自己以防其它CPU的干扰，所以锁住内存总线将完全是在浪费时间。）通过把LOCK宏放在内嵌编译指令的前边，随后的指令就会为SMP内核而被锁定。如果CPU B在CPU A发挥作用时执行了atomic_dec函数，那么CPU B就会自动的等待CPU A把锁移开。这样就能够成功了！这样还只能说是差不多。最初的问题仍然没有被很好的解决。目标不仅是要自动递减引用计数值，而且还要知道结果值是否是0。现在可以完成原子递减了，可是如果另一个处理器在递减和结果测试之间又“偷偷的”进行了干预，那又怎么办呢？幸运的是，解决这个部分问题不需要来自CPU的特殊目的的帮助。不管加锁还是未锁，x86的decl指令总是会在结果为0时设置CPU的Zero标志位，而且这个标志位是CPU私有的，所以其它CPU的所为是不可能在递减步骤和测试步骤之间影响到这个标志位的。相应的，atomic_dec_and_test（10249行）如前完成一次加锁的递减，接着依据CPU的Zero标志位来设置本地变量c。如果递减之后结果是0函数就返回非零值（真）。如同其它定义在一个文件里的函数一样，atomic_dec和atomic_dec_and_test都对一个类型为atomic_t的（10205行）对象进行操作。就像LOCK，atomic_t对于UP和SMP也有不同的定义方式——不同之处在于SMP情况里引入了volatile限定词，它指示gcc不要对被标记的变量做某种假定（比如，不要假定它可以被安全的保存在一个寄存器里）。顺便提及一下，读者在这段代码里看到的垃圾代码__atomic_fool_gcc据报告已不再需要了；它曾用于纠正在gcc的早期版本下代码生成里的一个故障。<H3 13pt 0cm">Test-And-Set</H3>经典的并行原语是test-and-set。test-and-set操作自动地从一个内存位置读取一个值然后写入一个新值，并把旧值返回。典型的，该位置可以保存0或者1，而且test-and-set所写的新值是1——因此是“设置（set）”。与test-and-set对等的是test-and-clear，它是同样的操作除了写入的是0而不是1。一些test-and-set的变体既能写入1也可以写入0，因此test-and-set和test-and-clear就能够成为一体，只是操作数不同而已。test-and-set原语足以实现任何其它并行安全的操作。（实际上，在某些CPU上test-and-set是唯一被提供的此类原语。）比如，原本test-and-set是能够用于前边的例子之中来保护引用计数值的。相似的方法以被尝试——从一个内存位置读取一个值，检查它是否为0，如果是则写入一个1，然后继续访问受保护的值。这种尝试的失败并不是因为它在逻辑上是不健全的，而是因为没有可行的方法使其自动完成。假使有了一个原子的test-and-set，你就可以不通过使用lock来原子化decl的方法而顺利通过了。然而，test-and-set也有缺点：l 它是一个低级的原语——在所有与它打交道时，其它原语都必须在它之上被执行。l 它并不经济——当机器测试该值并发现它已经是1了怎么办呢？这个值在内存里不会被搞乱，因为只要用同样的值复写它即可。可事实是它已被设置就意味着其它进程正在访问受保护的对象，所以还不能这样执行。额外需要的逻辑——测试并循环——会浪费CPU时钟周期并使得程序变得更大一些（它还会浪费高速缓存里的空间）。x86的lock指令使高级指令更容易执行，但是你也可以在上执行原子test-and-set操作。最直接的方式是把lock和btsl指令（位test-and-set）联合起来使用。这种方法要被本章后边介绍的自旋锁（spinlock）所用到。另一种在x86上实现的方法是用它的xchg（exchange）指令，它能够被x86自动处理，就好像它的前面有一个lock指令一样——只要它的一个操作数是在内存里。xchg要比lock/ btsl组合更为普遍，因为它可以一次交换8、16，或者32位而不仅仅是1位。除了一个在arch/i386/kernel/entry.S里的使用之外，内核对xchg指令的使用都隐藏在xchg宏（13052行）之后，而它又是在函数__xchg（13061行）之上实现的。这样是便于在平台相关的代码里内核代码也可以使用xchg宏；每种平台都提供它自己对于该宏的等价的实现。有趣的时，xchg宏是另一个宏，tas（test-and-set——13054行）的基础。然而，内核代码的任何一个地方都没有用到这个宏。内核有时候使用xchg宏来完成简单的test-and-set操作（尽管不必在锁变得可用之前一直循环，如同第22770行），并把它用于其它目的（如同第27427行）。<H3 13pt 0cm">信号量</H3>第9章中讨论了信号量的基本概念并演示了它们在进程间通信中的用法。内核为达自己的目的有其特有的信号量实现，它们被特别的称为是“内核信号量”。（在这一章里，未经修饰的名词“信号量”应被理解为是“内核信号量”。）第9章里所讨论的基本信号量的概念同样适用于内核信号量：允许一个可访问某资源用户的最大数目（最初悬挂在吊钩上钥匙的特定数目），然后规定每个申请资源者都必须先获得一把钥匙才能使用该资源。到目前为止，你大概应该已经发现信号量如何能够被建立在test-and-set之上并成为二元（“唯一钥匙”）信号量，或者在像atomic_dec_and_test这样的函数之上成为计数信号量的过程。内核正好就完成着这样的工作：它用整数代表信号量并使用函数down（11644行）和up（11714行）以及其它一些函数来递减和递增该整数。读者将看到，用于减少和增加整数的底层代码和atomic_dec_and_test及其它类似函数所使用的代码是一样的。作为相关历史事件的提示，第一位规范信号量概念的研究者，Edsger Dijistra是荷兰人，所以信号量的基础操作就用荷兰语命名为：Proberen和Verhogen，常缩写成P和V。这对术语被翻译成“测试（test）”（检查是否还有一把钥匙可用，若是就取走）和“递增（increment）”（把一个钥匙放回到吊钩之上）。那些词首字母正是在前一章中所引入的术语“获得（procure）”和“交出（vacate）”的来源。Linux内核打破了这个传统，用操作down和up的称呼取代了它们。内核用一个非常简单的类型来代表信号量：定义在11609行的struct semaphore。他只有三个成员：l count——跟踪仍然可用的钥匙数目。如果是0，钥匙就被取完了；如果是负数，钥匙被取完而且还有其它申请者在等待它。另外，如果count是0或负数，那么其它申请者的数目就等于count的绝对值。Sema_init宏（11637行）允许count被初始化为任何值，所以内核信号量可以是二元的（初始化count为1）也可以是计数型的（赋予它某个更大的初始值）。所有内核信号量代码都完全支持二元和计数型信号量，前者可作为后者的一个特例。不过在实践中count总是被初始化为1，这样内核信号量也总是二元类型的。尽管如此，没有什么能够阻止一个开发者将来增加一个新的计数信号量。要顺便提及的是，把count初始化为正值而且用递减它来表明你需要一个信号量的方法并没有什么神秘之处。你也可以用一个负值（或者是0）来初始化计数值然后增加它，或者遵循其它的方案。使用正的数字只是内核所采用的办法，而这碰巧和我们头脑中的吊钩上的钥匙模型吻合得相当好。的确，正如你将看到的那样，内核锁采用的是另一种方式工作——它被初始化为负值，并在进程需要它时进行增加。l waking——在up操作期间及之后被暂时使用；如果up正在释放信号量则它被设置为1，否则是0。l wait——因为要等待这个信号量再次变为可用而不得不被挂起的进程队列。down11644：down操作递减信号量计数值。你可能会认为它与概念里的实现一样简单，不过实际上远不是这样简单。11648：减少信号量计数值——要确保对SMP这是自动完成的。对于SMP来说（当然也适于UP），除了被访问的整数是在一个不同类型的struct之内以外，这同在atomic_dec_and_test中所完成的工作本质上是相同的。 读者可能会怀疑count是否会下溢。它不会：进程总是在递减count之后进入休眠，所以一个给定的进程一次只能获得一个信号量，而且int具有的负值要比进程的数目多的多。11652：如果符号位被设置，信号量就是负值。这意味着甚至它在被递减之前就是0或者负值了，这样进程无法得到该信号量并因此而应该休眠一直到它变成可用。接下来的几行代码十分巧妙地完成了这一点。如果符号位被设置则执行js跳转（即若decl的结果是负的它就跳转），2f标识出跳转的目的地。2f并非十六进制值——它是特殊的GNU汇编程序语法：2表示跳转到本地符号“2”，f表示向前搜索这个符号。（2b将表示向后搜索最近的本地符号“2”。）这个本地符号在第11655行。11653：分支转移没有执行，所以进程得到了信号量。虽然看起来不是这样，但是这实际已经到达down的末尾。稍后将对此进行解释。11654：down的技巧在于指令.section紧跟在跳转目标的前面，它表示把随后的代码汇编到内核的一个单独的段中——该段被称为.text.lock。这个段将在内存中被分配并标识为可执行的。这一点是由跟在段名之后的ax标志字符串来指定的——注意这个ax与x86的AX寄存器无关。 这样的结果是，汇编程序将把11655和11656行的指令从down所在的段里转移到可执行内核的一个不同的段里。所以这些行生成的目标代码与其前边的行所生成的代码从物理上不是连续的。这就是为什么说11653行是down的结尾的原因。11655：当信号量无法得到时跳转到的这一目的行。Pushl $1b并不是要把十六进制值1b压入栈中——如果要执行那种工作应该使用pushl $0x1b（也可以写成是不带$的）。正确的解释是，这个1b和前边见到的2f一样都是GNU汇编程序语法——它指向一个指令的地址；在此情形中，它是向后搜索时碰到的第一个本地标识“1”的地址。所以，这条指令是把11653行代码的地址压入栈中；这个地址将成为返回地址，以便在随后的跳转操作之后，执行过程还能返回到down的末尾。11656：开始跳转到__down_failed（不包括在本书之内）。这个函数在栈里保存几个寄存器并调用后边要介绍的__down（26932行）来完成等待信号量的工作。一旦__down返回了，__down_failed就返回到down，而它也随之返回。一直到进程获得了信号量__down才会返回；最终结果就是只要down返回，进程就得到信号量了，而不管它是立刻还是经过等待后获得的它。11657：伪汇编程序指令.previous的作用未在正式文档中说明，但是它的意思肯定是还原到以前的段中，结束11654行里的伪指令.section的作用效果。down_interruptible11664：down_interruptible函数被用于进程想要获得信号量但也愿意在等待它时被信号中断的情况。这个函数与down的实现非常相似，不过有两个区别将在随后的两段里进行解释。11666：第一个区别是down_interruptible函数返回一个int值来指示是否它获得了信号量或者被一个信号所打断。在前一种情况里返回值（在result里）是0，在后一种情况里它是负值。这部分上是由11675行代码完成的，如果函数未经等待获得了信号量则该行把result设置为0。11679：第二个区别是down_interruptible函数跳转到__down_failed_interruptible（不包括在本书之内）而不是__down_failed。因循__down_failed建立起来的模式，__down _failed_interruptible只是调整几个寄存器并调用将在随后进行研究的__down_interruptible函数（26942行）。要注意的是11676行为__down_failed_ interruptible设置的返回目标跟在xorl之后，xorl用于在信号量可以被立刻获得的情况中把result归0。down_interruptible函数的返回值再被复制进result中。down_trylock11687：除了调用__down_failed_trylock函数（当然还要调用26961行的__down_trylock函数，我们将在后面对它进行检查）之外，down_trylock函数和down_interruptible函数相同。因此，在这里不必对down_trylock函数进行更多解释。DOWN_VAR26900：这是作为__down和_down_interruptible共同代码因子的三个宏中的第一个。它只是声明了几个变量。DOWN_HEAD26904：这个宏使任务tsk（被DOWN_VAR所声明）转移到task_state给出的状态，然后把tsk添加到等待信号量的任务队列。最后，它开始一个无限循环，在此循环期间当__down和__down_interruptible准备退出时将使用break语句结束该循环。DOWN_TAIL26926：这个宏完成循环收尾工作，把tsk设置回task_state的状态，为再次尝试获得信号量做准备。26929：循环已经退出；tsk已或者得到了信号量或者被一个信号中断了（仅适于__down_ interruptible）。无论哪一种方式，任务已准备再次运行而不再等待该信号量了，因此它被转移回TASK_RUNNING并从信号量的等待队列里被注销。__down26932：__down和__down_interruptible遵循以下模式：1. 用DOWN_VAR声明所需的本地变量，随后可能还有补充的本地变量声明。2. 以DOWN_HEAD开始进入无穷循环。3. 在循环体内完成函数特定的（function-specific）工作。4. 重新调度。5. 以DOWN_TAIL结束。注意对schedule的调用（26686行，在第7章里讨论过）可以被移进DOWN_TAIL宏中。6. 完成任何函数特定的收尾工作。我将只对函数特定的步骤（第3和第6步）进行讨论。26936：__down的循环体调用waking_non_zero（未包括），它自动检查sem->waking来判断是否进程正被up唤醒。如果是这样，它将waking归零并返回1（这仍然是同一个原子操作的一部分）；如果不是，它返回0。因此，它返回的值指示了是否进程获得了信号量。如果它获得了值，循环就退出，接着函数也将返回。否则，进程将继续等待。 顺便要说明的是，观察一下__down尝试获得信号量是在调用schedule之前。如果信号量的计数值已知为负值时，为什么不用另一种相反的方式来实现它呢？实际上它对于第一遍循环之后的任何一遍重复都是没有影响的，但是去掉一次没有必要的检查可以稍微加快第一遍循环的速度。如果需要为此提出什么特别的理由的话，那可能就是因为自从信号量第一次被检查之后的几个微秒内它就应该可以被释放（可能是在另一个处理器上），而且额外获取标志要比一次额外调度所付出的代价少得多。因此__down可能还可以在重新调度之前做一次快速检查。__down_interruptible26942：__down_interruptible除了允许被信号中断以外，它和__down在本质上是一样的。26948：所以，当获取信号量时对waking_non_zero_interruptible（未包括）进行调用。如果它没能得到信号量就返回0，如果得到就返回1，或者如果它被一个信号所中断就返回–EINTR。在第一种情况下，循环继续。26958：否则，__down_interruptible退出，如果它得到信号量就返回0（不是1），或者假如被中断则返回–EINTR。__down_trylock26961：有时在不能立刻获得信号量的情况下，内核也需要继续运行。所以，__down_trylock不在循环之内。它仅仅调用waking_nonzero_trylock（未包括），该函数夺取信号量，如果失败就递增该信号量的count（因为内核不打算继续等待下去）然后返回。up11714：我们已经详尽的分析了内核尝试获得信号量时的情况，也讨论了它失败时的情况。现在是考察另一面的时候了：当释放一个信号量时将发生什么。这一部分相对简单。11721：原子性地递增信号量的计数值。11722：如果结果小于等于0，就有某个进程正在等待被唤醒。up向前跳转到11725行。11724：up采用了down里同样的技巧：这一行进入了内核的单独的一段，而不是在up本身的段内。up的末尾的地址被压入栈然后up跳转到__up_wakeup（未包括）。这里完成如同__down_failed一样的寄存器操作并调用下边要讨论的__up函数。__up26877：__up函数负责唤醒所有等待该信号量的进程。26897：调用wake_one_more（未包括在本书中），该函数检查是否有进程在等待该信号量，如果有，就增加waking成员来通知它们可以尝试获取它了。26880：利用wake_up宏（16612行），它只是调用__wake_up函数（26829行）来唤醒所有等待进程。__wake_up26829：正如在第2章中所讨论的那样，__wake_up函数唤醒所有传递给它的在等待队列上的进程，假如它们处于被mode所隐含的状态之一的话。当从wake_up被调用时，函数唤醒所有处于TASK_UNINTERRUPTIBLE或TASK_INTERRUPTIBLE状态的进程；当从wake_up_interruptible（16614行）被调用时，它只唤醒处于TASK_INTERRUPTIBLE状态的任务。26842：进程用wake_up_process（26356行）被唤醒，该函数曾在以前提到过，它将在本章随后进行详细介绍。现在所感兴趣的是唤醒所有进程后的结果。因为__wake_up唤醒所有队列里的进程，而不仅仅是队列里的第一个，所以它们都要竞争信号量——在SMP里，它们可以精确的同时做这件事。通常，获胜者将首先获得CPU。这个进程将是拥有最大“goodness”的进程（回忆一下第7章中26338行对goodness的讨论）。 这一点意义非常重大，因为拥有更高优先权的进程应该首先被给予继续其工作的机会。（这对于实时进程尤其重要。）这种方案的不足之处是有发生饥饿（starvation）的危险，这发生在一个进程永远不能得到它赖以继续运行的资源时。这里可能会发生饥饿现象：假如两个进程反复竞争同一个信号量，而第一个进程总是有比第二个更高的优先权，那么第二个进程将永远不会得到CPU。这种场景同它应该的运行方式存在一定差距——设想一个是实时进程而另一个以20的niceness运行。我们可以通过只唤醒队列里第一个进程的方法来避免这种饥饿的危险，可是那样又将意味着有时候会耽误从各个方面来说都更有资格的进程对CPU的使用。以前对此没有讨论过，可是Linux的调度程序在适当的环境下也能够使得CPU的一个进程被彻底饿死。这不完全是一件坏事——只是一种设计决策而已——而且至少应用于通篇内核代码的原则是一致的，这就很好。还要注意的是使用前边讨论过的其它机制，饥饿现象也同样会发生。例如说，test-and-set原语就是和内核信号量一样的潜在饥饿根源。无论如何，在实际中，饥饿是非常少见的——它只是一个有趣的理论案例。<H3 13pt 0cm">Spinlocks</H3>这一章里最后一个重要的并行程序设计原语是自旋锁（spinlock）。自旋锁的思想就是在一个密封的循环里坚持反复尝试夺取一个资源（一把锁）直到成功为止。这通常是通过在类似test-and-set操作之上进行循环来实现的——即，旋转（spinning）——一直到获得该锁。如果这听起来好像是一个二元信号量，那是因为它就是一个二元信号量。自旋锁和二元信号量唯一的概念区别就是你不必循环等待一个信号量——你可以夺取信号量，也可以在不能立刻得到它时放弃申请。因此，自旋锁原本是可以通过在信号量代码外再包裹一层循环来实现的。不过，因为自旋锁是信号量的一个受限特例，它们有更高效的实现方法。自旋锁变量——其中的一位被测试和设置——总是spinlock_t类型（12785行）。只有spinlock_t的最低位被使用；如果锁可用，则它是0，如果被取走，则它是1。在一个声明里，自旋锁被初始化为值SPIN_LOCK_UNLOCKED（12789行）；它也可以用spin_lock_init函数（12791行）来初始化。这两者都把spinlock_t的lock成员设置成0——也就是未锁状态。注意12795行代码简洁地对公平性进行了考虑并最后抛弃了它——公平是饥饿的背面，正如我们前面已经介绍过的（使得一个CPU或进程饥饿应被认为是“不公平的”）。自旋锁的加锁和解锁宏建立在spin_lock_string和sping_unlock_string函数之上，所以这一小节只对spin_lock_string和sping_unlock_string函数进行详述。其它宏如果有的话只是增加了IRQ加锁和解锁。spin_lock_string12805：这个宏的代码对于所有自旋锁加锁的宏都是相同的。它也被用于x86专用的lock_ kernel和unlock_kernel版本之中（它们不在本书之列，不过其常规版本则是包括的——参见10174和10182行）。12807：尝试测试和设置自旋锁的最低位，这要把内存总线锁住以便对于任何其它对同一个自旋锁的访问来说这个操作都是原子的。12808：如果成功了，控制流程就继续向下运行；否则，spin_lock_string函数向前跳转到第12810行（btsl把这一位的原值放入CPU的进位标志位（Carry flag），这正是这里使用jc的原因）。同样的技巧我们已经看到过三次了：跳转目标放在内核的单独一段中。12811：在封闭的循环里不停地检测循环锁的最低位。注意btsl和testb以不同方式解释它们第一个操作数——对于btsl，它是一个位状态（bit position），而对于testb，它是一个位屏蔽（bitmask）。因此，12811行在测试spin_lock_string曾在12807行已经试图设置（但失败了）的同一位，尽管一个使用$0而另一个使用$1。12813：该位被清除了，所以spin_lock_string应该再次夺取它。函数调转回第12806行。 这个代码可以只用加上lock前缀的两条代码加以简化： 1: lock ; btsl $0, %0 jc 1b 不过，使用这个简化版本的话，系统性能将明显受到损害，这因为每次循环重复内存总线都要被加锁。内核使用的版本虽然长一些，但是它可以使其它CPU运行的更有效，这是由于该版本只有在它有充分理由相信能够获得锁的时候才会锁住内存总线。spin_unlock_string12816：并不很重要：只是重新设置了自旋锁的锁定位（lock bit）。读/写自旋锁自旋锁的一个特殊情况就是读/写自旋锁。这里的思想是这样的：在某些情况中，我们想要允许某个对象有多个读者，但是当有一个写者正在写入这个对象时，则不允许它再有其它读者或者写者。遵循基于spinlock_t的自旋锁的同样模式，读/写自旋锁是用rwlock_t（12853行）来代表的，它可以在有RW_LOCK_UNLOCKED（12858行）的声明里被初始化。与rwlock_t一起工作的最低级的宏是read_lock、read_unlock、write_lock，以及write_unlock，它们在本小节中进行描述。很明显，那些跟随在这些宏之后并建立在它们之上的宏，自然要在你理解了最初的这四个宏之后在去接触。正如第12860行注释中所声明的，当写锁（write lock）被占有时，rwlock_t的lock成员是负值。当既没有读者也没有写者时它为0，当只有读者而没有写者时它是正值——在这种情况下，lock将对读者的数目进行计数。read_lock12867：开始于rwlock_t的lock成员的自动递增。这是推测性的操作——它可以被撤销。12868：如果它在增量之后为负，表示某个进程占用了写锁——或者至少是某个进程正试图得到它。read_lock向前跳到第12870行（注意，在一个不同的内核段里）。否则，没有写者退出（尽管还有可能有，或者也有可能没有其它读者——这并不重要），所以可以继续执行读锁定（read-locked）代码。12870：一个写者出现了。read_lock取消第12867行增值操作的影响。12871：循环等待rwlock_t的lock变为0或正值。12873：跳回到第12866行再次尝试。read_unlock12878：不太复杂：只是递减该计数值。write_lock12883：表示出有一个进程需要写锁：检测并设置lock的符号位并保证lock的值是负的。12884：如果符号位已经被设置，则另外有进程占有了写锁；write_lock向前跳转到第12889行（同以前一样，那是在一个不同的内核段里）。12885：没有别的进程正试图获得该写锁，可是读者仍可以退出。因为符号位被设置了，读者不能获得读锁，但是write_lock仍然必须等待正在退出的读者完全离开。它通过检查低端的31位中是否任何一位被设置过开始，这可以表示lock以前曾是正值。如果没有，则lock在符号位反转之前曾是0，这意味着没有读者；因而，这对于写者的继续工作是很安全的，所以控制流程就可以继续向下运行了。不过，如果低端31位中任何一位被设置过了，也就是说有读者了，这样write_lock就会向前跳转到第12888行等到它们结束。12888：该进程是仅有的写者，但是有若干读者。write_lock会暂时清除符号位（这个宏稍后将再次操纵它）。有趣的是，对符号位进行这样的胡乱操作并不会影响读者操纵lock的正确性。考虑作为示例的下列顺序事件：1. 两个读者增加了lock；lock用十六进制表示现在是0x00000002。2. 一个即将成为写者的进程设置了符号位；lock现在是0x80000002。3. 读者中的一个离开；lock现在是0x80000001。4. 写者看到剩余的位不全部是0——仍然有读者存在。这样它根本没有写锁，因此它就清除符号位；lock现在是0x00000001。 这样，读和写可以任何顺序交错尝试操作而不会影响结果的正确程度。12889：循环等待计数值降到0——也就是等待所有读者退出。实际上，0除了表示所有读者已离开之外，它还表示着没有其它进程获得了写锁。12891：所有读者和写者都结束了操作；write_lock又从头开始，并再次获得写锁。write_unlock12896：不太重要：只是重置符号位。<H2 13pt 0cm">APICs和CPU-To-CPU通信</H2>Intel 多处理规范的核心就是高级可编程中断控制器（Advanced Programmable Interrupt Controllers——APICs）的使用。CPU通过彼此发送中断来完成它们之间的通信。通过给中断附加动作（actions），不同的CPU可以在某种程度上彼此进行控制。每个CPU有自己的APIC（成为那个CPU的本地APIC），并且还有一个I/O APIC来处理由I/O设备引起的中断。在普通的多处理器系统中，I/O APIC取代了第6章里提到的中断控制器芯片组的作用。这里有几个示例性的函数来让你了解其工作方式的风格。smp_send_reschedule5019： 这个函数只有一行，其作用将在本章随后进行说明，它仅仅是给其ID以参数形式给出了的目标CPU发送一个中断。函数用CPU ID和RESCHEDULE_VECTOR向量调用send_IPI_single函数（4937行）。RESCHEDULE_VECTOR与其它CPU中断向量是一起在第1723行开始的一个定义块中被定义的。

我也说一句

发表

1万主题	49 听众	2万积分

TA的每日心情

	奋斗 2024-6-23 05:14

签到天数: 1043 天

[LV.10]以坛为家III

群组: 万里江山

群组: sas讨论小组

群组: C 语言讨论组

群组: Matlab讨论组

15^#

发表于 2005-3-4 22:24 |只看该作者 |招呼Ta 关注Ta

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">3GB。这是用户进程所能拥有的最大内存，在此基础上代码才有意义：显然，如果要求do_ mmap函数分配大于3GB的内存，或者在addr之后的3GB内存空间没有足够的空间，分配请求就必须被放弃。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33275：如果file为NULL，do_ mmap函数将被请求去执行匿名映射（anonymous mapping）操作，这是一种并不与任何一个文件或其它特别对象连接的映射过程。否则，映射将被关联到一个文件，接着do_ mmap函数要继续检查为内存区域设置的标志位是否与用户在文件上允许执行的操作相兼容。举例来说，在33278行，函数要确保是否内存区可写，因为文件已经被打开并执行写操作了。省略这项判断将可能使文件打开时所作的检查发生混乱。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33307：允许调用程序强调do_ mmap函数应该或者在要求的地址上提供映射操作，或者根本没有什么也不做。如果提供地址，do_ mmap函数只需保证提供的地址从一个页面的边界开始。否则，它将获得在addr处或之后的第一个可用地址（通过调用开始于33432行的get_unmapped_area函数），然后就使用这个地址。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33323：创建一个VMA并对其进行填写。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33333：如果内存映射着一个可读文件，则内存区域就被设为可读、可写和可执行。（do_ mmap函数可以很快的取消写许可——这只是假定）另外，如果要求共享该内存区域，那么现在就可以满足该请求。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33347：若文件不可写，则内存区域也必须不可写。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33351：在此情形中，没有这样的文件，使得do_ mmap函数必须与该文件的打开模式和许可权限相一致——就允许函数自由运行。因此，函数把内存区域设为可读、可写和可执行的。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33361：在地址范围建立时，利用do_munmap（很快就会被讨论到）来清除任何旧的内存映射。因为新的VMA还没有插入进程列表之中（只有do_ mmap函数当前知道它的存在），所以新VMA不会被此次调用影响。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33406：不会再有错误发生。do_ mmap函数把新VMA插入进程的VMA列表（或是它的AVL树），合并所有新近相连的段片（接下来会对merge_segments函数进行讨论），更新一些统计数字，并返回新映射的地址。<

3pt 0cm 3.2pt">Merge_segments<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33892：merge_segments函数是一个有趣的函数，它把相邻的VMA合并成单独的一个大范围的VMA。换句话说，如果一个VMA所覆盖（有意这样设计）范围是从0x100到0x200，而另一个VMA的覆盖范围是从0x200到0x300，并且两者保护信息相同，那么merge_segments函数就会用一个覆盖范围从0x100到0x300的单独VMA来代替它们。（注意函数名中的“segments”并不暗示此时我们采用CPU分段机制。）<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> merge_segments函数的参数是结构体struct mm_struct，它包含了我们该兴趣的VMA以及可能进行合并的开始地址和终止地址。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33897：find_vma_prev函数将其vm_end定位在给定的start_addr之后的第一个VMA上——由此，第一个VMA可能会包括start_addr。回忆一下find_vma_prev函数，它也返回一个指向前一个VMA的指针prevl（如果第一个VMA满足条件则该返回值是NULL）。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33911：进入处理所有覆盖给定区间的VMA的循环。在该循环过程中，merge_segments函数将尝试把每一个段片都与其前一个段片进行合并，而前一个段片的值可以通过prev获得。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33921：绝大部分条件判断都是相对直截了当的，不过最后一个测试就不这么简捷了。它确保prev和mpnt是连续的——也就是在prev的结尾和mpnt的开头之间没有未被映射的内存。即使检测结果是一个的vm_end和另一个的vm_start相等，这两块区域在这一点上也未必一定相互覆盖——回忆一下，vm_end是要比VMA拥有的最后地址还要大一位的。从33926行到33932行的代码为被映射文件和共享内存坚持了同样的特性：一块区域的末尾要等于下一块的开头。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33937：merge_segments函数找到了可以合并的VMA。它把mpnt从VMA列表（还可能是AVL树）里移出，再将它存入prev。要注意的是即使VMA的数目降到了MIN_MAP_COUNT以下，它都不会拆除AVL树。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33948：如果将要消失的VMA是一个被内存映射的文件的一部分，merge_segments函数就删除它对该文件的引用。<

3pt 0cm 3.2pt">do_munmap<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33689：do_munmap函数明显是do_mmap函数的反作用函数；它从一个进程的内存空间里废除虚拟内存映射。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33695：如果do_munmap函数被要求取消映射的地址不是页面对准的，或者地址区域位于进程的内存空间之外，那么很明显它就是无效的，因此请求就会被拒绝。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33699：如果连一个页面也没有被释放，就拒绝尝试。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33707：查找包括给定地址的VMA。令人奇怪的是，do_munmap函数返回的是0——而不是错误——如果地址不在任何一个VMA之内的话。从某种意义上讲，这是正确无误的；do_munmap函数被要求用来确保一个进程不再对特定内存区域进行映射，如果一开始就没有这种映射的话，那就很容易办到。不过这仍颇为奇怪；在调用者看来这是一个错误而且do_munmap函数也应该报告这个错误。然而，某些调用程序却希望它如33361行的示例那样执行工作。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33717：如果给出的内存区域整个在单独的一个VMA中，但又不在该VMA的一端，那么移去这段区域就会在封闭的VMA里生成一个空洞。内核是不会容忍这个空洞的，因为按照定义，VMA应该是连续的一段内存。因此在这种情况之下，do_munmap函数就需要创建另一个VMA，使得空洞的两边各有一个VMA。尽管如此，如果内核已经为该进程创建了所允许的所有VMA，那么函数就不能这样做了，所以此时do_munmap函数不能满足请求。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33730：标识所有与该区域相交迭或在区域里的VMA为空闲状态，同时把每一个都放在本地堆栈free里。顺着这个过程，do_munmap函数会把VMA从它们的AVL树中删除，如果有的话。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33743：do_munmap函数已经建造了要释放的VMA堆栈，现在释放它们。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">33748：计算要释放的准确范围，要牢牢记住的是这个范围可能不能以完整的VMA来度量。假如为min和max的定义适当，这三行可以被写成如下代码：<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> <

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> st = max ( mpnt -> vm_start, addr );<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> end = min ( mpnt -> vm_end, addr + len );<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt"> 由此，st是do_munmap函数实际开始释放区域的开头，end是该区域的结尾。33765：如果VMA是共享映射的一部分，do_munmap函数通过调用remove_shared_vm_ struct（33140行）来断开mpnt与共享VMAs列表的链接。33759：更新MMU数据结构，它对应于这个VMA里当前被释放掉的子区域。33765：调用unmap_fixup函数来修补映射，我们接下来就会对这个函数进行研究。33773：do_munmap函数已经释放了该范围内由VMA代表的所有映射；最后重要的一步就是要为同一区域释放页表，这是通过调用free_pgtables（33645行）实现的。Unmap_fixup33578：unmap_fixup函数修复给定VMA的映射，这可以或者通过对一端进行调整，或者通过在中间制造一个空洞，再或者通过把VMA完全删除的方法来完成。33590：第一种情况比较简单：去掉整个区间的映射。do_munmap函数仅仅需要关闭底下的文件或其它对象即可，如果它们有的话。读者可以看到，这无须把VMA本身从current->mm里移出；它已经被调用者删除了。因为VMA的全部范围将被解除映射，没有什么要向后推移的，所以unmap_fixup函数就此返回。33599：接下来的两种情况处理把VMA从开头到末尾一块区间移去的问题。这也是比较简单的；它们的主要工作是要调整VMA的vm_start或vm_end成员。33608：这是四种情况中最有意思的一种——从一个VMA的中间移去一块区域，从而会产生一个空洞。函数先开始要复制一份额外生成的VMA的本地拷贝，然后通过将*extra设置为NULL来通知调用程序该附加VMA已被使用。33611：图8-4表示了分裂VMA的过程。大部分信息被直接从旧VMA复制到了新VMA，在此之后，unmap_fixup函数对两个VMA的范围都作了调整以解决空洞问题。原先的VMA，area，被缩小到了表示低于空洞的子区域，而mpnt则表示高于空洞的子区域。33626：把全部新子区域插入current->mm。33629：在除了第一种的其它情况里，unmap_fixup函数保持了旧的VMA。它缩小了，但还未消失，因此它将被插回到VMA的current->mm集合中。 <v:shapetype><v:stroke joinstyle="miter"></v:stroke><v:path connecttype="rect" gradientshapeok="t"></v:path></v:shapetype><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1035"></v:textbox></v:shape><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV class=shape 7.2pt; PADDING-LEFT: 7.2pt; PADDING-BOTTOM: 3.6pt; PADDING-TOP: 3.6pt" v:shape="_x0000_s1035">Area -> vm_start addr end Area -> vm_end </DIV></TD></TR></TABLE> <v:shape><v:textbox style="mso-next-textbox: #_x0000_s1032"></v:textbox></v:shape><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV class=shape 7.2pt; PADDING-LEFT: 7.2pt; PADDING-BOTTOM: 3.6pt; PADDING-TOP: 3.6pt" v:shape="_x0000_s1032">befor</DIV></TD></TR></TABLE><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1028"></v:textbox></v:shape><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV class=shape 7.95pt; PADDING-LEFT: 7.95pt; PADDING-BOTTOM: 4.35pt; PADDING-TOP: 4.35pt" v:shape="_x0000_s1028"> </DIV></TD></TR></TABLE><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1027"></v:textbox></v:shape><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV class=shape 7.95pt; PADDING-LEFT: 7.95pt; PADDING-BOTTOM: 4.35pt; PADDING-TOP: 4.35pt" v:shape="_x0000_s1027"> </DIV></TD></TR></TABLE><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1026"></v:textbox></v:shape><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV class=shape 7.95pt; PADDING-LEFT: 7.95pt; PADDING-BOTTOM: 4.35pt; PADDING-TOP: 4.35pt" v:shape="_x0000_s1026"> </DIV></TD></TR></TABLE> <v:shape><v:textbox style="mso-next-textbox: #_x0000_s1029"><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV> </DIV></TD></TR></TABLE></v:textbox></v:shape><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1030"><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV> </DIV></TD></TR></TABLE></v:textbox></v:shape><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1031"><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV> </DIV></TD></TR></TABLE></v:textbox></v:shape><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1033"><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV>after</DIV></TD></TR></TABLE></v:textbox></v:shape><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1034"><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV>Area -> vm_start Area -> vm_end</DIV></TD></TR></TABLE></v:textbox></v:shape><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1036"><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV>Mpnt_ vm_start Mpnt_ vm_end</DIV></TD></TR></TABLE></v:textbox></v:shape> 图 8.4分裂VMA<H2 13pt 0cm">用户空间和内核空间</H2><H3 13pt 0cm">动态内存</H3>用户任务和内核本身都经常需要快速分配内存。C程序一般使用著名的malloc和free函数来完成这项工作；内核也有它自己类似的机制。当然，内核必须至少提供支持C语言的malloc和free函数的低级操作。在Linux平台上，就像其它的Unix变种一样，一个进程的数据区分为两个便于使用的部分，即栈（stack）和堆（heap）。为了避免这两个部分冲突，栈从（准确的是接近）可用地址空间的顶端开始并向下扩展，而堆从紧靠代码段上方开始并向上扩展。虽然可以使用mmap在堆和栈之间分配内存，但是这部分空间通常是没有使用的内存的空白地带。即使不去研究有关的内核代码（不过我们还是要继续这项工作），读者也能对这些地址区间所处位置有相当好的了解。下面的短程序显示了几个挑选出来的对象的地址，它们分处于三种不同内存区域之内。由于种种理由，我们不能保证它可以被移植到所有平台上，不过它可以在Linux的任何版本下工作，而且也应该可以被移植到你所尝试的大部分其它平台上。P515-1 代码在我的系统上，我得到了如下的数字。你的结果可能会稍有不同，除了所使用的编译器标志外，它还取决于你的内核及gcc的版本。即使不完全相同，它们也应该与下面结果相当接近。P515-2 代码从这里你不难看出，如果使用大概的数字的话，栈从接近0xC0000000处开始并向下生长，代码从0x8000000处开始，而堆则如前所述从临近代码上部的地方开始并向上扩展。Brk系统调用brk是一个在C库函数malloc和free底层的原语操作。进程的brk值是一个位于进程堆空间和它的堆、栈中间未映射区域之间的转折点。从另一个角度看，它就是进程的最高有效堆地址。堆位于代码段顶端和brk之间。如果brk底下的可用自由空间不够满足请求，C库函数malloc就抬高brk；如果被释放的空间位于brk之下，就降低brk。顺便说一句，Linux是我所知道的唯一的在使用free函数时真正的减少进程内存空间的Unix变体；其它我所经历过的所有Unix商业版本实际上都是保留该进程的空间的——显然这是“以防万一”的作法。（其它Unix的自由版本可能同Linux一样，不过我没有使用过。）另外，对于大量的分配工作，GNU的C库使用mmap和munmap系统调用来执行malloc和free。代码、数据，以及栈的关系如图8-5所示。<v:shape><v:textbox style="mso-next-textbox: #_x0000_s1037"><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV> </DIV></TD></TR></TABLE></v:textbox></v:shape><v:line></v:line><v:line><v:stroke endarrow="block"></v:stroke></v:line><v:shape><v:textbox><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV>stack</DIV></TD></TR></TABLE></v:textbox></v:shape><v:shape><v:textbox><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV>Free(possibility mmapped)</DIV></TD></TR></TABLE></v:textbox></v:shape><v:line></v:line><v:shape><v:textbox><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV>heap</DIV></TD></TR></TABLE></v:textbox></v:shape><v:line></v:line><v:line><v:stroke startarrow="block"></v:stroke></v:line><v:shape><v:textbox><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV>Code(fixed size</DIV></TD></TR></TABLE></v:textbox></v:shape> 图8.5 代码、数据和栈 Sys_brk33155：实现brk的函数是sys_brk。它可以修改进程的brk值，还可以返回一个新值。如果无法修改brk的值，返回的brk值就等于其原值。33177：如果brk的新值位于代码区域之中，它就明显偏低而必须被抛弃。33179：通过使用宏PAGE_ALIGN（10842行）把brk参数向上取整到地址更高的下一个页面。33180：按页对准进程原有的brk值。这看起来有些多余，因为如果进程的brk只是在这里被设置，它就一定是按页排列的。但是在初始化一个进程的时候，进程的brk可以被设置在别的地方，代码并不会把它按页对准排列。不管进程的brk在哪里被设置，把它按页对准都可能会快一些；允许内核在这里跳过一次页对准操作，而且由于此处要比别的地方更频繁的对进程的brk进行设置，它应该不会降低执行效率而且还会少许提高。33185：brk被降低了，不过还没有进入代码区域，因此尝试被允许。33192：如果堆的大小有限制，它就要被考虑。图8-5清楚的表明，brk - mm->end_code是堆的大小。33197：如果brk扩展到了已被一个VMA所内存映射的（mmapped）区域，它就是不可利用的，因此这个新brk值要被舍弃。33201：最后一项必要的检查是察看是否存在足够的自由页面用于空间分配。33205：使用do_mmap函数（33240行）为新区域分配空间。然后，sys_brk函数更新进程的brk的位置并返回新值。Vmalloc和vfree内核编程中一个有趣的方面是并没有像应用程序编程人员通常所想当然的那样能够得到很多服务。就拿malloc和free作为例子，它们就是建立在一个内核原语brk之上的C库函数。假使内核被修订以使其可以和标准C库连接，并使用它的函数malloc和free，那么最终结果将是既笨拙又缓慢——这些函数被要求从用户模式调用，所以内核将不得不切换到用户模式去调用它们，然后它们又不得不掉转回到内核，还必须要对整个过程进行监控，等等。为了避免这一切，内核有许多十分熟悉的函数的自己的版本，它们包括malloc和free在内。的确，内核提供了像malloc和free一样的两对独立的函数。第一对是kmalloc和kfree，管理在内核段内分配的内存——这是真实地址已知的实际和物理内存块。第二对是vmalloc和vfree，用于对内核使用的虚拟内存进行分配和释放。由kmalloc返回的内存更适合于类似设备驱动的程序来使用，因为它在物理内存里而且是物理连续的。不过，kmalloc要比vmalloc所能使用的资源少，因为vmalloc还可以处理交换空间。vmalloc和vfree的一部分也是通过kmalloc和kfree来实现的，因为它们需要一部分不可交换的内存用于登记操作（bookkeeping）。kmalloc和kfree又依次使用__get_free_ pages、free_pages，以及其它低级页面操作函数实现的。在此我不对kmalloc和kfree进行解释，不过本书中提供了相关代码以供读者阅读（分别见37043和37058行）。我将要讨论的是更有意思的函数vmalloc和vfree。Vmalloc38776：vmalloc函数拥有一个参数，即要分配的内存区域的大小。函数返回指向分配区域的指针，如果无法分配就返回NULL。 Vmalloc可以分配内存的虚拟地址范围是由常量VMALLOC_START（11081行）和VMALLOC_END（11084行）决定的。VMALLOC_START从超过物理内存结束地址8MB的地方开始，以便对任何在这一区域错误的内核内存访问进行截获，VMALLOC_END在接近可能的最大32位地址4GB的地址处。除非你的系统拥有比我的系统多得多的物理内存，否则这就意味着几乎整个CPU地址空间都潜在的可为Vmalloc所用。38781：vmalloc函数首先把要求的区域大小向上取整到地址更高的下一个页面边界，如果它不在一个页面的边界上的话。（PAGE_ALIGN宏在10842行定义。）如果最终范围结果太小（0）或明显过大，则请求会被拒绝。38784：利用get_vm_area来为size大小的块定位一段足够大的内存区域，这个函数接下来会进行介绍。38788：通过调用vmalloc_area_pages（38701行）保证能够建立页表映射。38792：返回被分配的区域。get_vm_area38727：get_vm_area函数返回从VMALLOC_START到VMALLOC_END的一段自由内存区间。通常这就是vmalloc函数的工作；它还被用于我未曾提及的其它少数场合。调用程序有责任确保参数size是一个非零的页面大小的倍数值。 vmalloc函数采用所谓的首次适应算法（first-fit algorithm），因为它返回一个指向定位区域的指针，该区域是它所能找到的第一个满足请求的区域。除此而外，还有最佳适应算法（best-fit algorithm），该算法选取足够满足需求的最小的一块可用自由区域进行分配，以及最坏适应算法（worst-fit algorithm），该算法总是分配最大的一块可用自由区间。每种分配方式都有优点和缺点，不过首次适应算法在这里对要达到的目的来讲，就已经非常简单、快捷而且足以满足要求了。38732：分配一个struct vm_struct来代表新的区域。被分配的区域用一个有序链表，即vmlist（38578行）来维护，该链表是由struct vm_structs构成的。包括struct vm_struct结构体的头文件被省略以节约空间，不过结构体的定义十分简单： struct vm_struct { unsigned long flags; void* addr; unsigned long size; struct vm_struct* next; }; 如图8-6所示，链表的每一个元素都与单独一块已分配了的内存块相关联。形象的看起来，get_vm_area函数的任务就是在已分配的区域之间找出足够宽的间隔。<wrapblock><v:shapetype><v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path connecttype="rect" gradientshapeok="t" extrusionok="f"></v:path><lock aspectratio="t" v:ext="edit"></lock></v:shapetype><v:shape><v:imagedata></v:imagedata><w:wrap type="topAndBottom"></w:wrap></v:shape></wrapblock> 图8.6 VMLIST 列表 38737：沿着链表进行循环。循环的结果要么是找到一个足够大的自由区间，要么是证明这样的区域不存在。它会先从VMALLOC_START开始尝试，然后挨个尝试紧随着每块被分配区域之后的地址。38746：链表为空或者循环发现了一个足够大的新块；无论哪种情形，现在addr都是最小可用地址。填充新的struct vm_struct结构体，它将会被返回。38747：给保留块增加一个页面的大小（x86平台上是4K），来捕获内核超出的内存——可能的话还包括下一个更高地址块下方的内存。因为在决定是否当前区域足够大的时候（38738行）并没有把这些额外的空间算在内，那么保留区域可能会与接下来的一个相重叠，而且内核内存中超出而进入这个“额外”区域的部分也确实可能覆盖到被分配了的内存。事实不是如此吗？ 事实不是这样。我们很容易证明addr总是页对准的，而且我们也已知道size总是页面大小的倍数。因此，addr + size要小于接下来区域的开始地址，它至少是一整页。当然超出范围多于一页的内存会进入下一个区域，不过超出范围少于一页的内存就不会这样。 因为内核不会为额外内存建立页面映射，所以对它的错误访问将造成不可解决的页面错误（这在Linux的现代版本中几乎还未听说过！）。这将会带给内核一次痛苦的中断，不过那要比允许内核悄然无息地破坏自己的数据结构要好一些。至少你可以立刻知道这个折磨人的系统停机，它可以帮助你诊断问题所在；而后一种作法可能在内核已经破坏了你的磁盘之后，才能看出它的危害。Vfree38759：vfree函数比vmalloc简单得多（要是把get_vm_area加进vmalloc至少是这样的），不过为了完整起见，我们还是要对vfree略为讨论。当然addr是要被释放的已分配区域的开头地址。38763：在几项简洁而又完善的测试之后，函数沿着vmlist进行循环，搜索要释放的区域。这个线性查找过程使我想到一件有趣的事，假如采用一个如同VMA管理所用的AVL树那样的平衡树结构，也将会提高vmalloc和vfree函数的性能。38764：当与addr相匹配的struct vm_struct被找到时，vfree函数就把它从链表里分离出去，并释放该结构体和它所关联的页面，然后返回。每个struct vm_struct不仅记录它的初址还记录区域的大小，这一点对于get_vm_area是便利的，在这里同样也颇为便利，因此vfree函数是知道应该释放多大空间的。38772：如果vfree函数在链表里找到了匹配项，它在此之前就应该已经返回了，所以没有找到匹配项。这是一个坏事，不过还未糟糕到不可收拾的地步。这样，vfree函数以显示一个警告而结束。<H3 13pt 0cm">转储内核（Dumping Core）</H3>在一些情况之下，比如一个满是“臭虫”的程序试图去访问自己允许内存空间之外的内存时，进程可以转储内核。进行“转储内核”就是把一个进程的内存空间的映象（随同一些关于应用程序本身和其状态的识别信息一起）写入一个文件以备将来使用诸如gdb之类的调试器进行分析的过程（“内核”是一个差不多已经过时的内存术语）。当然，或许你的代码从来不会犯这样的错误，但是这可能会发生在你隔壁不太聪明的程序员身上，而他可能在某一天会向你询问这件事，因此在此我要对此问题进行一些讨论。不同的二进制处理程序完成转储内核的方式不同。（第7章里论述过二进制处理程序。）最常用的Linux二进制格式是ELF，所以我们来看看ELF二进制处理程序是如何进行转储内核的。Elf_core_dump8748： elf_core_dump 函数由此开始。因为一个进程转储内存是由接受到一个信号而引起的（它也可能发送给自己，例如通过对about的调用），该信号编号在signr中被给出。Signr对进程是否或者如何执行转储内存没有影响，但是在调试器里看内存文件的用户却想要知道是哪个信号导致内存转储的，它就像是一个关于出了什么错的提示一样。指向struct pt_regs（11546行）的regs参数包含一份对CPU寄存器的描述。regs的重要性除了一些其它原因之外还在于它包含了EIP寄存器的内容，该寄存器是指令指针，它决定了收到信号时所执行的指令。8771： 假如进程未通过一些基本检查则立即返回，这些检查中的第一个是确保dumpable标志被设置。进程的dumpable标志（16359行）通常会被设置；它的清除主要是在进程改变其用户或组ID的时候。这似乎是一项安全措施。例如我们将不愿意创建一个被设定为root的不可读执行程序的可读内存文件——那会使得保证执行体不可读（出于安全考虑）的目的遭到失败。 elf_core_dump 函数此时也会返回，假如内存文件的大小限制使得连一个页面也无法转储，或者如果有其它线程要引用将要转储的内存。转储内核是和退出进程相关的，从用户的角度看来，只要进程任何一个线程还存在，它就没有消亡。 如果进程通过了这些测试，elf_core_dump 函数就继续运行并清除dumpable位以便它不会再次尝试转储进程的内存。（尽管这种情形不能会发生；我认为这只是预防式的编程设计。）8785： 进入一个循环以对内存文件大小限制之内可以被转储的VMA个数进行计数。尽管elf_core_dump 函数把计数植保存在叫做segs的变量里，它并不表明我们正对本章中所使用过的“内存段”进行计数。不要认为这个变量的名字有其它特别的附加涵义。 由于elf_core_dump 函数在转储VMA之前要向内存文件写一些头部信息，而且这些头部的大小没有进行计算，因此输出结果可能会稍微超出内存文件的大小限制。这不难解决：一个简单的策略是在写入头部时递减limit，并把循环计数移动到头部写入代码之后。实际解决方案要更麻烦一些，不过也并不是十分复杂。8805： ELF内存文件格式根据正式规范进行定义；第一个部分是描述文件的头部。结构体struct elfhdr类型（参见14726和14541行）定义了头部的格式，elf_core_dump 函数填写这个类型的一个局部变量elf。8827： 创建要转储到的文件名，并尝试打开这个文件。通过把8828行的#if 0改变为#if 1，我们可以让内存文件名包括生成文件的执行程序的名字（或至少是名字的前16个字符——参见在16406行定义的struct task_struct的comm成员）。有的时候这是一个很有用的特性；能够一看到内存文件的名字就可以马上知道是什么应用生成的将是一件很好的事情。不过，这种行为并不标准，而且还有可能破坏已有代码——比如监视器脚本程序，它周期性地检查名为“code”的文件是否存在——所以缺省行为还是为遵守标准惯例而把文件命名为普通的“code”。尽管如此，发现这么一个可以调整的内核参数还是不错的。这个可选项也对8756行局部变量corefile那看似与众不同的定义方式进行了解释。8853： 设置PF_DUMPCORE标识（16448行），发出信号表明该进程正在转储内核。这个标识不在本书所涉及的任何代码中使用，它被用于读者将要了解的审计进程。审计进程（process accounting ）跟踪一个进程的资源使用情况和其它的一些相关信息——包括它是否在退出时转储内核——这些信息原本是用来帮助计算中心计算应向每个资源使用部门或用户收取多少费用的。这些日子都已经离我们远去了，难道我们不应该为此而感到高兴吗？8855： 写入早先建立的ELF内存文件头部。这里要涉及一些隐含的流控制：定义在8707行的DUMP_WRITE宏使得elf_core_dump 函数在写操作失败时关闭文件并返回。8862： 跟在ELF内存文件头部之后的是一系列节点（note）；它们中的每一个都有特殊目的，记录着有关进程的特定信息。我们将逐一对其论述。一个注解（数据类型是struct memelfnote，8666行）包括一个指向辅助数据（它的data成员）的指针和该数据的长度（它的datasz成员）；填写一个注解的大部分工作就是填充辅助数据结构，然后使该注解指向它。 有些信息被存储在若干个注解里。代码中没有对这种重复进行解释，但是其中至少有一部分原因是从Unix的变种中拷贝它们的行为方式。保持文件格式和其它平台一致有助于把诸如gdb这样的程序移植到Linux上来；少许重复要比延迟移植版本的进度和增加诸如此类的关键工具的维护复杂要好得多。8865： 注解0在辅助数据结构体（类型struct_elf_prstatus；参见14774行）里记录了进程的继承关系、信号量，以及CPU的使用情况。我们需要特别注意8869行的elf_core_dump，它存储了引起进程转储内核的信号编号。所以当你（或者是你隔壁那个初级程序员）在一个内存文件上运行gdb而它显示”Program terminated with signal 11, Segmentation fault”的时候，你就会知道该信息是从哪里来的了。8916： 注解1在辅助数据结构体psinfo（属于类型struct_elf_prpsinfo；参见14813行）里记录了进程的属主、状态，优先级等等信息。8922行有一个虽然正确，但很不寻常的指向一个文字字符串常量的数组下标；被选择的字符是进程状态的一个记忆码。这与ps程序的STAT域报告的状态字是一样的（除非下标溢出）。更有意思的是8945行，代码把执行体的名字（如前所述，最多16个字符）复制进了注解。Gdb和程序“文件”都用这个字段来报告是哪一个程序生成的内核转储。8948： 节点2记录转储进程的struct task_struct，这明显存储了关于该进程的大量必要信息。因为struct task_struct内的一些信息是由当调试器检查代码时便不再有效的指针组成的，elf_core_dump 函数随后还会分别转储一些指针所指向的信息——最紧要的，如进程的内存空间。8954： 如果这个系统包含一个FPU（浮点计算单元），那么就会据此而生成一个注解。否则，8957行对所要存储的注解数目进行递减。8968： 对于每个被创建的注解，都有一个描述该注解的头部；而注解本身会紧随其后。注解头是struct elf_phdr类型；参见14727和14581行它的定义。8992： 这是写入进程内存空间的第一步。在这里，函数写入头部信息（又一次是phdr），该头部描述了它将要写入的所有VMA。9016： 最后，elf_core_dump 函数才真正地写入它先前辛辛苦苦创建好的各个注解（内存文件）。9022： 在文件里向前跳过4K到达下一个边界，内存文件真正的数据是从这里开始的。完成此项操作的DUMP_SEEK宏在8710行定义，像DUMP_WRITE宏一样，假如搜索失败它也会导致elf_core_dump 函数的返回。9024：在所有那些准备之后，这里的工作简直有些虎头蛇尾。不过，这才是转储内核的主要部分：写入进程的每一个VMA直至先前计算出并保存在segs里的上限。接下来是少许收尾工作，然后elf_core_dump 函数就完成了使命。

我也说一句

发表

1万主题	49 听众	2万积分

TA的每日心情

	奋斗 2024-6-23 05:14

签到天数: 1043 天

[LV.10]以坛为家III

群组: 万里江山

群组: sas讨论小组

群组: C 语言讨论组

群组: Matlab讨论组

14^#

发表于 2005-3-4 22:22 |只看该作者 |招呼Ta 关注Ta

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">的结束地址小，这样它就可能比VMA的初始地址还要小。因此这一点要被检查。假如通过判断，则address在VMA之内，控制就会向前跳转到标号good_area处（第7023行）；我们随后就会对这一点进行讨论。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7005： 如果find_vma返回空值NULL，那么address就位于进程的所有VMA之后——换句话说就是超出了由进程引用的所有内存。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7009： vma的开头和结尾都确实超过了address；因此address在VMA低端地址以下。但是这并不会失去什么。如果VMA是向下扩展的类型——也可以说它是堆栈——这个堆栈可以简单的向下扩展来适应那个地址。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7011： CPU提供的error_code的测试位2。与监控（内核）模式相比，更多是在用户模式发生页面错误时设置此位。如果是在用户模式下，do_page_fault函数会保证给定的地址在为进程建立的堆栈区域内，正如ESP寄存器所定义的那样。（例如，在代码溢出了被分配的堆栈矩阵时，就会产生这种情况。）如果是在监控（内核）模式下，就会跳过后一种判断，而简单的假定内核运行正常。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7019： 如果可能，使用expand_stack（行15480）将扩展到包含新的地址。如果成功，VMA 的vm_start成员将调整到包含address。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7023： 到达good_area标记时，就意味着VMA包含address，或者说要么它已经包括了address，要么就是堆栈扩展后包括了该地址。<

0cm 0cm 0pt 36pt; TEXT-INDENT: 0cm">不管那一种方法，包括错误产生原因信息的error_code最低两位现在都可以被测试了。第0位是存在/保护位：0表示该页不存在；1表示该页存在，但试图的访问操作与页级保护位冲突。第1位是读/写位：0表示读，1表示写。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7025： switch条件判断语句对于上述两个测试位所组合出的四种可能情况作出相应处理：<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l0 level1 lfo1; tab-stops: list 57.25pt">l case 2或3——检查包括的VMA是否可写。若可写，就是向一个写拷贝页面执行一次写操作；变量write被增加（设置到1）以便接下来对hand_mm_fault的调用能够完成写拷贝过程。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l0 level1 lfo1; tab-stops: list 57.25pt">l case 1——这意味着页面错误是由试图从一个存在但不可读的页面中读数据而导致的；这个尝试会被拒绝。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l0 level1 lfo1; tab-stops: list 57.25pt">l case 0——表示页面错误是由试图从一个不存在的页面中读数据而导致的。如果涉及的VMA保护指出该区间既不可读也不可写，读页面只不过是浪费时间——如果再次尝试，将引起另一个页面错误，这样do_page_fault函数会以case 1的结果告终，即拒绝尝试。否则do_page_fault函数继续执行并从磁盘上读入页面。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7047： 请求handle_mm_fault函数（下面讨论）使该页面变为当前页面。如果失败，则发出一个SIGBUS错误。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7062： 大多数内核函数的清除代码都不太显著。do_page_fault函数是一个例外；我们会比较详尽的研究它的清除代码。下列任何情况发生都会跳到bad_area标记处：<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l2 level1 lfo2; tab-stops: list 57.25pt">l 被引用的地址超过了为进程分配的（或保留的）所有内存。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l2 level1 lfo2; tab-stops: list 57.25pt">l 被引用的地址位于所有VMA之外，而且可能由于比该地址小的VMA不是堆栈而无法扩展到这个地址。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l2 level1 lfo2; tab-stops: list 57.25pt">l 违反了页面的读/写保护。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7066： 如果用户代码引起以上任何错误，那将发送致命的SIGSEGV信号——一个分段违例。（注意术语“分段”在这里是历史上的说法而不是字面所表达的意思——对CPU来说，从技术角度看它是分页违例，不一定是分段违例。）这个信号通常会像第6章中讨论的那样杀死一个进程。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7075： Intel Pentium CPU（以及它的一些兼容产品）具有一个所谓的f00f缺陷，它允许任何进程用非法的0xf00fc7C8指令来冻结CPU。Intel所提议的弥补工作就是在这里实现的：中断描述表（见第6章）的一部分以前是被标识为只读的，因为这样会使非法指令执行时用产生页面错误代替冻结CPU。在这里，do_page_fault函数检查导致页面错误的地址是否位于IDT中由非法指令执行而产生的位置上。如果是这样的，处理器会试着执行“Invalid Opcode”服务中断——CPU的缺陷会使得正确完成这一步失败，而代码却会通过直接调用do_invalid_op函数而产生正确的结果。否则，CPU决不会对IDT进行写操作（即使没有标注为只读时也是如此），所以即使第7080行的检测失败，非法指令也是根本不会被执行的。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7086： 下列情况发生时，标记no_context会被执行：<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l4 level1 lfo3; tab-stops: list 57.25pt">l 在内核（不是用户）模式里到达bad_area，而且CPU不执行触发f00f缺陷的非法指令。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l4 level1 lfo3; tab-stops: list 57.25pt">l 在一个中断中或没有用户环境（用户任务没有处于正在执行状态）时发生的页面错误。<

0cm 0cm 0pt 57.25pt; TEXT-INDENT: -21.25pt; mso-list: l4 level1 lfo3; tab-stops: list 57.25pt">l Handle_mm_fault函数错误并且系统处于内核模式中（我还从未遇到过这种情况）。<

0cm 0cm 0pt 36pt; TEXT-INDENT: 0cm">这里的任何一种情形都是内核错误（经常由驱动程序所导致），它不是因为任何用户代码而造成的页面错误。如果内核（或驱动程序）事先为这种可能准备了错误处理代码，那么这些错误处理代码一定位于本书讨论范围之外，并在错误发生时可以通过某种特殊技术跳转过去。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7097： 否则，内核试图访问一个坏页面，do_page_fault函数将不知如何处理它。这可能也够被考虑到。内核启动代码检查是否MMU写保护工作正常；如果正常，那就不是一个真正的错误，do_page_fault函数就可以简单的返回了。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7109： 内核访问了一个坏页面，并且do_page_fault函数无法修复这个错误。do_page_fault函数会在第7129行显示出一些描述错误的信息，然后中止内核本身。这样整个系统就会被停止，很明显没有任何操作会被执行。不过，如果系统运行到了这一步，内核也别无选择了。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">7134： 最后一个标记是do_sigbus，只有当handle_mm_fault函数无法处理错误时才会执行到这里。这种情况相对简单；大体上是给违例的进程发送一个SIGBUS错误信号，如果这是在内核模式里发生的就再跳回到no_context标记处。<

3pt 0cm 3.2pt">Handle_mm_fault<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">32725：调用者已经检测到了需要一个可用的页面。该页面正是包含address的页面，这个地址应归入vma中。Handle_mm_fault函数本身相当简洁，但是它建立在其它几个处理冗长细节问题的函数和宏之上。我们介绍完此函数后将逐一研究那些底层函数。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">32732：查找关联的页目录和页面中间目录入口项（如前所述，这两者在x86平台上实际是一样的）。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">32735：从页面中间目录项得到或定位（如果可能的话）页表。32737：调用handle_pte_fault函数把页面读入页表项（page table entry）；如果成功，就调用update_mmu _cache函数更新MMU的高速缓存。控制流程到此为止，一切顺利，handle_mm_fault函数就可以返回一个非零值（1）表示成功了。如果此过程任何一步出错，控制就转向第32744行，函数返回0值表示失败。Pgd_offset11284：这个宏将address除以2PGDIR_SHIFT（第11052行#defined to 32），并对结果向下舍入，然后把最终结果（移位之前的高端10位）作为提供的struct mm_struct的pgd数组的一个索引。因此，它的值就是页目录项，相应的页表address地址就位于该项中。 这等价于代码&((mm)->pgd[(address)>>PGDIR_SHIFT]);而且可能会更高效。Pmd_alloc11454：因为x86平台上没有定义页面中间目录，这样就极其简单：它只需返回给定的pgd指针，并映射为一种不同类型。在其它平台上，该函数与pte_alloc类似，还要实现更多的工作。Pte_alloc11422：Pte_alloc函数有两个参数：一个是指针，指向目标地址所位于的页面中间目录项，另一个是地址本身。如果我们暂时跳过一部分内容，那么对该函数经过变形的逻辑的理解就会更容易，所以让我们看一下随后的若干行代码。11425：用一种几乎无法理解的方式把address转换成PMD内的一个偏移量。这一行需要详细进行解释。首先，回忆一下PMD中的每项都是一个指针，在x86平台上它的长度是4个字节（这里的代码是与体系结构相关的，所以我们可以作出这样的假定）。用C语言来定义就是， &pmd[middle_10_bits(address)] （为清晰起见，我在这里引入了假定的pmd数组和middle_10_bits函数）该代码等价于 pmd+middle_10_bits(address) 这又与如下代码指向的地址相同 ((char*)pmd)+middle_10_bits(address)*sizeof(pte_t*) 其技巧是在最后的公式中——或者更准确的说是+号后边的部分——最接近于第11425行所要计算的实际值。为了使这一点更为明确，首先可知 4*(PTRS_PER_PTE-1) 就是4092（第11059行PTRS_PER_PTE被定义为1024）。用二进制表示，4092只用占最低12位，甚至最后2位也用不上。它和只占最低10位的1023左移2位后的值相同。这样就有 (address>>(PAGE_SHIFT-2)) 把address右移10位（第10790行PAGE_SHIFT被定义为12）。这两个表达式结果再逐位进行与（AND）操作。最终的结果类似于： ((address>>PAGE_SHIFT)&(PTRS_PER_PTE-1))<<2 尽管这仍很复杂，不过它更简单明了：它把address右移12位（为了去掉页面偏移量部分），屏蔽掉除最低10位的其它位（去掉页目录索引部分，只保留最低10位的页面中间目录索引），接着把结果左移2位（相当于乘以4，即指针长度的字节数sizeof(pte_t*)）。更直接的方法可能会稍慢一些，但在内核里，我们终归是要尽力节省时间的。（虽然更直接的方法看来并非明显偏慢：同样版本内核进行两次移位、两次减法，以及按位与的操作，和进行两次移位、两次按位与的操作，就我的测试看来实际上是一样快。）不管采用那一种方法，经过计算之后，把address和PMD的基地址相加（在第11432行和别的地方执行），就得到了指向与address初值关联的PTE的项指针。11428：如果PMD项不指向任一个页表，函数向前跳到getnew处分配一个页表。11435：通过调用get_pte_fast（第11357行）尝试从pte_quicklist中申请一个页表。这个页表是页表的一个高速缓存，其思想是分配页表（它们本身就是独立的页面）慢，而从一系列近期释放的页表中指定一个却会稍快一些。所以，代码经常用free_pte_fast（第11369行）来释放页表，这会把它们放在pte_quicklist里而不是确实把它们消除掉。11439：pte_quicklist能够提供一个页表页面。页表可以被送入页面中间目录，并且函数返回页表中这个页面的偏移值。11438：pte_quicklist缓存里没有剩下页面，因此pte_alloc需要调用get_pte_slow函数（第7216行）来分配一个缓慢页面。该函数用__get_free_page来分配页面，执行过程和一个页面被找到时相似。11430：如果PMD项不是0，但是是无效的，pte_alloc显示一个警告（通过调用第7187行的bad_pte）并放弃尝试。11432：所期待的正常情况：pte_alloc函数返回一个指向包括address地址的PTE的指针。Handle_pte_fault32690：Handle_pte_fault函数试图取回或者创建一个缺少的PTE。32702：给定的项与物理内存中的任何一个页面都无关联（32700行），而且确实没有被设置（32701行）。这样，do_no_page（32633行）将被调用以创建一个新的页面映射。32704：页面在内存中不存在，但是它有一个映射，所以它一定在交换空间里。函数do_swap_page（32569行）将被调用来把该页面读回内存。32708：页面在内存里，所以情况可能是内核正在处理一个页面保护冲突。Handle_pte_fault首先要用pte_mkyoung（11252行）来把该页面标识为已被访问。32713：如果是一个写访问操作而页面又不是可写的，Handle_pte_fault就调用do_wp_page函数（32401行）。这个函数完成真正的写拷贝功能，因此我们要简单介绍一下。32715：这是一次对可写页面的写访问。Handle_pte_fault设置该页面的“dirty”位，表示在它被丢弃之前必须被复制到交换空间。32720：所需的页面现在可被调用者使用，所以Handle_pte_fault函数返回非零值（确定为1）以示成功。Update_mmu_cache11506：在x86平台上，update_mmu_cache函数是一个空操作。它是一种所谓的“挂钩（hook）”函数——这种函数要在内核的平台无关部分中适当地点处保证被调用，以便不同的移植版本都能够在必要的情况下对它进行定义。Do_wp_page32401：如前所述，真正的写拷贝操作是在这里实现的，所以我们有必要介绍一下。tsk试图写入address，这个地址在给定的vma里并由所提供的page_table来控制。32410：调用__get_free_page（15364行，简单的转向第34696行调用__get_free_pages函数）为进程提供一个新页面，此页面是写保护页面的一个新拷贝。注意这里可以允许一个任务转换。有趣的是，这里的代码不检查__get_free_page分配新页面时是否成功——它实际上可能不需要新的页面，因此到必要时才会去进行检查。32422：增加“次要（minor）”页面错误，这些错误无需访问磁盘就可被满足。32438：只有两个页面用户存在，其中一个是交换高速缓存（swap cache），它是已被交换出但还未被回收的页面的临时缓冲池。该页面被移出交换高速缓存后（利用37686行的函数delete_from_swap_cache），现在它就只有一个用户了。32445：要么从交换高速缓存里回收该页面，要么它只有一个开始用户。这个页面会被标识为可写和“脏”dirty（因为它已被写过）。32448：如果已分配了一个新页面，它就没有用了：由于该页面只有一个用户，所以没有必要进行复制。do_wp_page函数释放这个新页面，并返回非零值表示成功。32454：页面拥有不止一个用户，不能简单的从交换高速缓存里被收回。因此do_wp_page函数将需要复制一个新页面。如果先前的页面分配失败，现在就是该结果产生作用的时候了，do_wp_page函数将不得不返回错误。32459：利用copy_cow_page（31814行）复制页面内容。这通常是调用copy_page宏（32814行），它是一个memcpy。32460：利用flush_page_to_ram（10900行）使RAM新旧页面拷贝同步。像update_mmu _cache函数一样，在x86平台上这是一个空操作。32463：像以前一样，使得页面可写和“脏”，同时保留从封装的VMA而来的其它页面保护（比如可执行）。32466：对函数free_page（在15386行，它只是调用34633行的free_pages函数）的调用而不会真正释放旧的页面，因为该页面拥有多个用户——它只会减少旧页面被引用的次数。由于满足了调用者的请求，do_wp_page就返回非零值表示成功。<H4 14pt 0cm 14.5pt">页面调出</H4>现在读者已经对交换页面调入有所了解，接下来看一看另一方面，交换页面的调出。Try_to_swap_out38863：try_to_swap_out函数是最低一级交换调出函数，它由内核任务kswapd（见39272行kswapd函数）周期性地调用（通过一系列其它函数调用）。这个函数用来写一个页面，该页面是由位于给定任务特定VMA中的一个单独页表项来控制的。38873：如果内存中缺少该页面，它就不能从内存写回到磁盘，这样try_to_swap_out函数就返回失败。如果给定的地址明显是不合法的（max_mapnr是当前系统中物理内存的页面数目；参见7546行），它也会丢弃尝试操作。38880：如果页面被保留、锁住，或者被一个外设用于直接内存访问时，它就不能被调出。38885：如果页面最近被访问过，把它调出可能是不明智的，因为引用的局部性可能会使该页面不久将再被引用。把该页面标识成“旧的”，这样将来的再一次尝试就可能把它调出内存——这可能很快就会发生，如果内核不顾一切要这么做的话。但事实是，页面还没有被调出。这一行之后的代码注释本身就含有大量信息，所以我们将跳过几段代码而不失完整性。38965：减少任务的驻留段长度（注意vma->vm_mm是指向含有vma的struct mm_struct的指针）。驻留段长度是物理内存中的任务所占页面数目，而且很明显，这些页面中的一个现在已经不存在了。38968：因为页面无效，所以try_to_swap_out函数必须通知所有TLB以无效化它们对该页面的引用。TLB不应该再把地址解析到一个已经不存在了的页面。try_to_swap_out函数接着把这个页面放入交换缓存。38977：最后，try_to_swap_out函数通过使用rw_swap_cache（35186行）把旧的页面写回磁盘，写操作是异步的，以便等待磁盘处理时系统也可以作其它工作。38979：用__free_page（34621行）来释放页面，并返回非零值表示成功。<H2 13pt 0cm">交换设备</H2>Linux拥有一个按优先级排序的合法交换设备列表（以及文件，不过为了简单起见，这一部分通常用“设备”来代替这两者）。当需要分配一个交换页面时，Linux会在仍然拥有空间的优先级最高的交换设备上来分配它。Linux也会在所有优先级相同的未满交换设备之间轮转使用，采用的是循环方式，通过这种在多个磁盘上分布分页请求的方法可以提高交换的性能。在等待第一个请求被满足时，另一个请求就可以分派到下一个磁盘上。最快的设置是把交换分区分布在几个相似的磁盘上，并给它们同样的优先级设置；而较慢的磁盘则有稍低一些的优先级。不过循环也可能造成交换速度的降低。如果同一磁盘上的多个交换设备有同样的优先级，那么磁盘的读/写头将不得不在磁盘上来回的反复访问它们；在这种情况下，臭名卓著的1000倍的速度差异就不容忽视了。幸运的是，系统管理员会合理安排优先级以避免这种情况。Linux继承了Unix的传统特性，既能让你陷入绝境，也能使你达成非常良好的目标。最简单的方案是给每个交换设备分配不同的优先级；这会有助于避免最坏的情况，但可能也不会最好。尽管如此，由于该方法简单且不会最坏，如果你不指定优先级设置，它将是缺省设置。交换设备用struct swap_info_struct（17554行）结构体类型来表示。在37834行定义了这些结构体的一个数组swap_info。好几个文件里的函数都操作和使用swap_info数组来进行交换管理；很快我们就会对它们进行分析。先来分析一下struct swap_info_struct的成员，这会使我们能够更清楚的了解这些函数。l swap_device——发生交换的设备号；如果struct代表一个文件而不是分区，值是0。l swap_file——struct代表的交换文件或分区l swap_map——对交换空间里每个交换页面的用户数进行计数的数组；为0则表示页面空闲。l swap_lockmap——用来跟踪基于磁盘的页面当前是否正被读出或写入磁盘，数组里的每一位对应一个页面。在I/O过程中页面将被锁定以防止内核同时对同一页面执行两次I/O操作，或者其它类似的愚蠢操作——需要记住的是，一旦有可能，其它进程就会与I/O操作相重叠，所以发生这种情况并非难事。l lowest_bit和highest_bit——跟踪交换设备里第一个和最后一个可用的页面的位置。这可以有助于加快寻找空闲页面的循环。设备的第一个页面是一个不允许用于交换的头部，因此lowest_bit不会是0。l cluster_next和cluster_nr——用来对磁盘上的交换页面进行分组以获得更高的效率。l prio——交换设备的优先级。l pages——设备上可用的页面数目。l max——内核在此设备中所允许的最大页面数目。l next——把swap_info数组中的所有struct形成一个单独的链接列表（并保持优先级顺序）。这样，数组就被逻辑排序，而不是物理排序了。next的值就是列表中逻辑指向下一个元素的索引，如果到达列表末尾它就是-1。swap_list在37832行定义，包括列表头（即head成员――参见17627行struct swap_list_t的定义）的索引；如果列表为空则此索引为-1。它还包括名字很令人迷惑的next成员，这个成员能够跟踪我们将要在其上尝试页面分配的下一个交换设备。因此next是一个迭代指针。如果列表为空或者当前没有交换，它的值就是-1。Get_swap_page37879：get_swap_page函数从最高优先级的拥有空间的可用交换设备里获得一个页面；如果找到一个，它就返回一个非零代码描述该项，如果系统没有交换就返回0。37885：从上一次停止的地方继续进行迭代。如果列表是空的或没有剩余交换设备，函数即刻返回。37891：否则的话，有理由确信存在交换空间，get_swap_page函数恰恰需要找到它。这个循环过程一直迭代，直到函数找到一项（很可能的情形）或者扫描了每一个交换设备但没有一个还有剩余空间（不太可能的情形）为止。37894：利用scan_swap_map（37838行）扫描当前交换设备的swap_map以寻找一个空闲单元，如果找到了一项，lowest_bit和highest_bit成员也会被更新。要返回的offset是0或者是该项。37897：当前的交换设备能够分配一个页面。get_swap_page函数现在把swap_map的迭代游标向前推进以便请求能被正确的分布在交换设备上。如果已经到达交换设备列表的末尾或是下一个交换设备的优先级低于当前设备，迭代过程就会从列表的头部重新开始。这产生两个重要作用：l 如果较高优先级设备的交换空间又变得可用，get_swap_page就会在下一次迭代时从那个设备开始分配交换。如果孤立的观察这些代码，读者会认为当高优先级设备可用的时候，这个函数仍可以从低优先级设备分配少数页面。然而事实并非如此，在我们对交换页面是如何被释放进行介绍的时候读者就会看到这一点。l 如果优先级高的交换设备不可用，那么在下一次内核分配一个交换项时，get_swap_page函数将沿列表进行迭代直到它找到当前优先级的第一个设备为止，并试着从那个设备分配交换。因此，在内核转向优先级较低的设备之前，内核会继续考虑优先级较高的设备直至它们全部耗尽。这就是先前讨论过的循环执行过程。37910：当前设备没有可用的交换空间，或者当前设备是不可写的（这与我们所说的是同样的）。跳到下一个设备，这样如果它已经到达末尾但还未曾循环一整圈时，它就会再从头开始循环。37916：如果get_swap_page函数到达列表的末尾而且已经循环了一遍，它就已经考虑了所有交换设备但是没有一个拥有空余的空间。因此，结论是再也没有可用的交换空间了，函数返回0。Swap_free37923：swap_free函数是与get_swap_page函数相对的，它释放一个单独的交换项。37939：通过许多简单而又周密的测试后，swap_free函数检查是否正在释放交换页面的设备具有比随后将被考虑的设备更高的优先级。如果是，它就把此作为一个线索以将swap_list的迭代器重新设置在列表头部。这样对get_swap_page函数的下一次调用就会从列表头部开始并能够检测到新近被释放的高优先级空间。37944：假如最新被释放的页面处于lowest_bit和highest_bit成员所定义的范围之外，就要相应的对它们进行调整。你可以看到如果swap_free函数在一个以前已经耗尽了的设备中释放页面，这通常会引起对lowest_bit或者highest_bit的调整，但并非都要调整。这会使该区间比所需要的大，交换页面分配也会因此比所需要的要慢。不过这种情况很少发生。无论如何，交换范围都将调整自己以使更多的交换页面能够被分配和释放。37950：对swap_map每一元素的使用计数只维护到一个最大值，即SWAP_MAP_MAX（17551行定义为32767）。达到这个最大值之后，内核将无法知道真正的计数值有多大；由此它也无法安全的减少该值。否则的话，swap_free函数将减少使用计数并增加空闲页面的总数。Sys_swapoff38161：sys_swapoff函数在可能情况下从交换设备列表中移去被指明的交换设备。38178：搜索swap_info_structs的列表以查找匹配的项，设置p指向这个数据项、type指向该数据项的索引，以及prev指向前一项的索引。如果第一个元素被删除，prev将是-1。38195：如果sys_swapoff函数搜索了整个列表但没有找到匹配项，那显然是给定了一个无效的名字。函数返回错误。38198：如果prev是负值，sys_swapoff函数将删除列表的第一个元素；它相应的适当更新swap_list.head。可以证明，这等价于 swap_list.head= swap_info[swap_list.head].next 不过速度更快，因为其中所牵扯的间接转换更少。38203：如果正被移去的设备是内核进行交换尝试的下一个设备，迭代游标会被重新设置在列表头部。这样下一次分配可能要稍慢一点儿，不过并不显著；无论如何，实际中这样的情况是相当少见的。38209：由于设备仍在使用中而不能被释放时，它会被恢复到列表的适当地方。如果这是数个拥有同样优先级交换设备之中的一个，它可能不会回到同以前一样的相对位置了——它将是具有同样优先级的设备的第一个而不是最后一个——不过列表仍然是按照优先级进行排序的。从交换设备列表上删除一个仍有可能被我们又放回原处的设备，这看起来就象是在做无用功——为什么不等到可以确信它可以被删除时再删除它呢？答案在于经由一系列利用swap_list的函数调用后，在前面代码行对try_to_unuse（38105行）的调用能够结束。 如果正被删除的交换设备那时仍在swap_list里，那么终止这一切的代码将会给系统造成极大的混乱。38223：若在一个分区上进行交换，sys_swapoff函数将解除对它的引用。38244：sys_swapoff函数以使所有数据域无效和释放已分配的内存而告终。特别的，这行代码清除SWP_USED位，这样内核就会在它再次利用该交换设备时知道它已经是不可用的了。接下来，sys_swapoff函数清除err指示符并返回成功。Sys_swapon38300：sys_swapon函数是sys_swapoff的对应函数，它向系统列表里增加交换设备或交换文件。38321：找寻未用的一个项。这里有一些微妙之处。读者可能会从nr_swapfiles的名字推断出它就是交换文件（或者设备）的数目，但是实际它不是。它是曾被使用过的swap_info的最大索引值，而且从不会被降低。（它记录着这个数组被使用的最高峰值。）因此，把swap_info中的这许多项循环一遍的结果是，要么发现未用的一个项，要么在最后一次循环增量后让p指向第nr_swapfiles项之后。在上述的后一种情况下，若nr_swapfiles比MAX_ SWAPFILES小，那么所有用过的项恰好会排在数组的左边，而循环就使得p指向它们右边的一个空位。这样，nr_swapfiles就会被更新。 有趣的是，即使nr_swapfiles不是最高峰值而是活动交换设备的计数值，循环也能正确执行。不过若我们改变了nr_swapfiles的原意，文件里的其它代码就会有问题了。38328：在swap_info里找到了一个未用的项；sys_swapon函数开始对其进行填充。这里所提供的一些值将会发生变化。38338：若SWAP_FLAGS_PREFER被置位，swap_flags的低端15位就被编码为所需的优先级。（这里使用的常量和接着的几行代码在17510行进行定义。）否则，就不指定优先级。如前所述，在此情况下的缺省作法是给每一个设备分派一个逐渐降低的优先级，其目的是在无须人工干预时也能得到令人满意的交换性能。38344：保证内核允许交换的文件或设备可以被打开。38352：检查提供给sys_swapon函数的是一个文件还是一个分区。若S_ISBLK返回为真，它就是一个块设备，即磁盘分区。在此情形下，sys_swapon函数继续确保能够打开该块设备而且内核此时没有同它进行交换。38375：同样的，若给定的不是分区，sys_swapon函数必须确保它是一个普通文件。若是文件，函数还要确保内核此时没有同该文件进行交换。38384：如果两项测试均告失败，sys_swapon函数就不会再被请求在磁盘分区或文件上进行交换；它已经拒绝了该尝试。38396：从交换设备里把头页面读入swap_header；这是一个在17516行定义的union swap_ header联合体类型。38400：检查一串特征字节序列，该序列记述了交换头部的版本信息，它是由mkswap程序给出的。38412：交换类型1。此时，该头页面被当作一个大的位映射图，每一位代表设备中剩下的一个可用页面。同其它页面一样，头页面也是4K字节，即32K比特。由于每一位表示一个页面，设备就可以拥有32768个页面，也就是每个设备总计128MB。（实际上要稍小一些，因为头页面的最后10位用于签名，这样我们就不能假定它们对应的80个页面也是可用的；另外头页面本身也不能用于交换。）如果实际设备比这个值小，那么头页面中的一些位就不起作用。在38417行，函数进入循环来检查哪些页面是可用的，并对它正在创建的swap_info_struct的lowest_bit、highest_bit以及max成员进行设置。 注意这个头页面位映射图不会永远被保持——当sys_swapon函数结束时它就会被释放。内核利用交换映射表来跟踪正在使用的页面；该头页面位映射图仅被用来设置lowest_bit和其它swap_info_struct结构体的成员。38427：分配交换映射表并把所有使用计数值设置为0。38440：交换类型为2的交换并没有减轻交换区容量的限制，不过它以一种更自然和有效的方式贮存头部的信息。在此情形之下，swap_header的info成员就包含了sys_swapon函数所需的信息。38451：新的交换头部版本不需要sys_swapon函数把头页面当作一个位映射图来计算lowest_bit、highest_bit，和max的值——lowest_bit总是1，另外两个值可以从明确储存在头部的信息在定长时间内计算出来。这要比执行32768次位测试的循环快的多也简单的多，而且后者的定义语句甚至比前者要多出两倍以上！尽管如此，这部分以及余下的工作从概念上讲还是与以前十分相似的；sys_swapon函数只不过是从交换头部直接获取了它所需要的大部分信息，而无须在计算它们而已。 读者现在可以看出我刚才撒的一个小谎；版本类型为2的交换实际上真正克服了交换区容量的限制。在这个版本中，文件末尾的80个页面不会由于交换头部签名而不可利用，因此单独一个设备有可以有320K用于交换。不过上限仍然是大概128MB。38491：sys_swapon函数忽略读取头部。它把设备交换映射表的第一个元素设置为SWAP_ MAP_BAD（17552行）以避免内核在头页面上进行交换。38492：分配加锁映射表并清零。38499：更新可用的交换页面总数，并对此结果显示一个消息。（在38502行，从移位计数器里减去10以便输出结果是千字节表示，210就是1K。）38505：在交换设备的逻辑列表中插入新元素，仍遵循优先级排序的顺序。这里的代码从功能上是与sys_swapoff函数中相应的代码一样的，所以没理由把它们分离开来。一个能代替两者的内嵌函数就能简单的解决问题。38519：进行清理工作，然后结束。<H2 13pt 0cm">内存映射mmap</H2>mmap是一个重要的系统调用，它允许为不同目的而设置专用的独享内存区域。该内存可能是一个文件或其它特别对象的代理，在这种情形中，内核将保持内存区域和潜在对象的一致，或者该内存可能是为一个应用程序所需要的简单的无格式内存。（应用程序通常不使用mmap来分配无格式内存区，因为此时malloc更符合其目的。）mmap最普遍的使用方法之一是为内核本身通过内存映射（memory-map）形成一个可执行文件（参见8323行的一个例子）。这是关于二进制处理程序如何同分页机制协同工作以提供所需要分页的可执行体，这正如本章早些时候所暗示的。可执行体通过mmap被映射为进程内存空间中的适当区域，然后do_page_fault函数调入执行体所需的剩余页面。被mmap分配的内存可能被标识为可执行，其中充满了指令代码，随后系统跳入其中开始执行；这正是Java Just-In-Time（JIT）编译器的工作方式。更简单的说，可执行文件能够被直接映射成一个正在运行的进程的内存空间；这项技术用于动态连接库的执行中。执行mmap功能的内核函数是do_ mmap。do_ mmap33240：do_ mmap函数具有几个参数；它们共同定义应在内存中映射的文件或设备，并决定将被创建的内存区域的首选地址及其它特性。33252：TASK_SIZE和在10867行定义的PAGE_OFFSET值相同——即是0xc0000000或

我也说一句

发表

1万主题	49 听众	2万积分

TA的每日心情

	奋斗 2024-6-23 05:14

签到天数: 1043 天

[LV.10]以坛为家III

群组: 万里江山

群组: sas讨论小组

群组: C 语言讨论组

群组: Matlab讨论组

13^#

发表于 2005-3-4 22:18 |只看该作者 |招呼Ta 关注Ta

<H1 17pt 0cm 16.5pt; TEXT-ALIGN: center" align=center>第8章 内存</H1><

0cm 0cm 0pt">内存是内核所管理的最重要的资源之一。某进程区别于其它进程的一个特征是两个进程存在于逻辑上相互独立的内存空间（与之相反，线程共享内存）。即使进程都是同一程序的实例，比如，两个xterm或两个Emacse，内核都会为每个进程安排内存空间，使得它们看起来像是在系统之上运行的唯一进程。当一个进程不可能偶然或恶意的修改其它进程的执行空间时，系统的安全性和稳定性就会得到增强。<

0cm 0cm 0pt">内核也生存在它自己的内存空间之中，即内核空间（kernel space）。与之对应的是用户空间（user space），它是所有非内核任务所处的内存空间的一个通用术语。<H2 13pt 0cm">虚拟内存</H2><

0cm 0cm 0pt">计算机系统包括不同级别的存储器。图8-1说明了这些存储器中最重要的几项，并且以我自己原有的Linux机器（Linux box）为例标注了一些参数的估计值。当你从左向右观察该图时，会发现存储器容量越来越大而速度却越来越慢（而且每字节价格也会更低）。尤其令人注意的是，访问速度跨越了3个数量级（乘数因子为1000），而容量竟跨越了超过8个数量级（乘数因子为312500000）。（实际上有时速度的差异是可以被掩盖的，不过这些数字足以很好的说明这一部分讨论的目的。）最大的差距体现在最后两个：RAM和磁盘上，它们又分别可被称作主存和辅存。<

0cm 0cm 0pt">额外附加的存储器空间总是十分诱人的，即使它们也很慢。如果在RAM被用完时，通过暂时把不用的代码和数据转移到磁盘上以腾出更多空间的方法来使用磁盘代替RAM的话，那将是很好的一件事情。正如读者可能已经知道的，Linux恰好能够做到这一点，这被称之为虚拟内存（virtual memory）。<

0cm 0cm 0pt">虚拟内存是一种对RAM和磁盘（或称之为：主存和辅存）进行无缝混合访问的技术。所有这些（虚拟）内存对于应用程序来说就好像它真的存在一样。当然我们知道它并非真的内存，这正是为什么它被称为是“虚拟的”，但是多亏了内核使得应用程序无法分辨出它们的区别。对于应用程序来说，就好像真的有很大数量的RAM，只不过有时候比较慢而已。<

0cm 0cm 0pt">术语“虚拟内存”还有另外一层意思，从严格意义来讲是与前述的第一种意思没有关系的。这里的虚拟内存指的是对进程驻留地址进行欺骗的方法。每个进程都会有这样一种错觉，认为它的地址是从0开始并由此连续向上发展的。很明显，这一点同时对所有进程都成立是不可能的，但是在生成代码的时候这个假定（fiction）却能够带来很大方便，这是由于进程不必知道它们是否真正从0地址开始驻留，而且它们也不必去关心此事。<

0cm 0cm 0pt">这两种意思也不必相关，因为一个操作系统从理论上可以给每个进程分配一个独有的逻辑地址空间而不用混合使用主存和辅存。然而在所有我已经知道的系统中（对这两种虚拟内存的实现方式）要么都采纳要么都不采纳，这一点可能会在开始时令人感到困惑。<

0cm 0cm 0pt">为了避免这种意义上的分歧，有人倾向于术语“虚拟内存”代表逻辑地址空间（logical- address-space）的意义，同时使用“分页（paging）”或“交换”表示磁盘作为内存使用（disk-as-memory）的含义。尽管这种严格的区分具有充足的理由，但是我更喜欢普通的用法。除非上下文要求，否则我很少花费精力对它们进行区分。<

0cm 0cm 0pt"> <

0cm 0cm 0pt"><v:shapetype><v:stroke joinstyle="miter"></v:stroke><v:path connecttype="rect" gradientshapeok="t"></v:path></v:shapetype><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1026"></v:textbox></v:shape><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1028"></v:textbox></v:shape><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1030"></v:textbox></v:shape><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1029"></v:textbox></v:shape><v:shape><v:textbox style="mso-next-textbox: #_x0000_s1027"></v:textbox></v:shape><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV class=shape 7.95pt; PADDING-LEFT: 7.95pt; PADDING-BOTTOM: 4.35pt; PADDING-TOP: 4.35pt" v:shape="_x0000_s1026"><

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>Registers<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center> <

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>32 bytes<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>9 ns<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center> </DIV></TD></TR></TABLE><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV class=shape 7.95pt; PADDING-LEFT: 7.95pt; PADDING-BOTTOM: 4.35pt; PADDING-TOP: 4.35pt" v:shape="_x0000_s1027"><

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>On-chip<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>(L1)cache<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>16K<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>9 ns<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>On-chip<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>(L2)cache<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>256K<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>20 ns<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>RAM<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center> <

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>96MB<

0cm 0cm 0pt; TEXT-ALIGN: center" align=center>70 ns </DIV></TD></TR></TABLE><TABLE cellSpacing=0 cellPadding=0 width="100%"><TR><TD #d4d0c8; BORDER-TOP: #d4d0c8; BORDER-LEFT: #d4d0c8; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent"><DIV class=shape 7.95pt; PADDING-LEFT: 7.95pt; PADDING-BOTTOM: 4.35pt; PADDING-TOP: 4.35pt" v:shape="_x0000_s1029">Hard Disk 10GB9 ms </DIV></TD></TR></TABLE> 图8-1 具有速度和容量的存储级别<H3 13pt 0cm">交换和分页</H3>早期的虚拟内存（VM）系统仅能够把整个应用程序代码和数据，即完整的进程从磁盘上移出或移入磁盘。这种技术被称为交换（swapping），因为它是把一个进程同另一个进程进行了对调。出于这个原因，磁盘上为VM所保留的区域通常被称为交换空间（swap space），或简称为交换区（swap），尽管如我们所见，现代的系统已不再使用这种最初意义上的交换技术。与此类似，读者通常会见到的术语是交换设备（swap device）和交换分区（swap partition），它是磁盘分区的同义词，但是被专门作为交换空间使用，以及术语交换文件（swap file），这是一个用于交换的规则的、有固定长度的文件。交换是很有用的，当然要比根本没有VM好的多，但是它也有一定局限性。首先，交换需要把整个进程同时调入内存，所以当运行一个需要比系统所有RAM还要大的存储空间的进程时，交换便于事无补了，即使磁盘有大量空间可供补充。其次，交换可能会很低效。交换就必须把整个进程同时调出，这就意味着为了2K的空间你不得不把一个8MB的进程整个调出。同样的道理，即使仅仅需要执行被调进的应用程序代码的一小部分，你也必须把整个进程同时调进。分页（paging）是把系统的内存划分成很小的块，即页面，每个页面可以独立的从磁盘调入或调出磁盘。分页与交换技术相似，但它使用更加细小的粒度（granularity）。分页比交换有更多的登记（book-keeping）开销，这是因为页面数远比进程数要多，然而通过分页可以获得更多的灵活性。而且分页也更快一些，原因之一就是不再需要把整个进程调进调出，而只需要交换必要的页面就足够了。要记住前述的1000倍的速度差异，所以我们应该尽可能避免磁盘的I/O操作。传统上特定平台上页面的大小是固定的，比如x86平台为4K，这可以简化分页操作。不过，大多数CPU为可变大小的页面提供硬件支持，通常能够达到4M或者更大。可变大小页面可以使分页操作执行更快和更有效，不过要以复杂性为代价。标准发行的Linux内核不支持可变大小页面，所以我们仍然假定页面大小是4K。（已经有支持Cyrix可变大小页面机制的补丁程序，但它们不是本书中官方发行版本的部分。而且据闻由此获得的性能增益也并不非常显著。）因为分页可以完成交换所能完成的所有工作，而且更加有效，所以类似于Linux一样的现代操作系统已不再使用交换，严格的说是只使用分页技术。但是术语“交换”已得到了广泛使用，以至于实际应用中术语“交换”和“分页”已经几乎可以通用；由于内核使用分页技术，所以本书就遵从这种用法。Linux能够交换到一个专用磁盘分区、或一个文件，或是分区和文件的不同组合。Linux甚至允许在系统运行时增加和移去交换空间，当你暂时需要额外大量的交换空间，或者假如你发现需要额外交换空间而又不想重启系统的时候，这就会很有用了。另外，与一些Unix的风格（flavors）不同，Linux即使没有任何交换空间也能运行得很好。<H3 13pt 0cm">地址空间</H3>地址空间（address space）是一段表示内存位置的地址范围。地址空间有三种：l 物理地址空间l 线性地址空间l 逻辑地址空间，也被称为虚拟地址空间（需要指出的是，I/O地址能够被看作是第四种地址空间，但是本书中对其不作讨论。）物理地址是一个系统中可用的真实的硬件地址。假如一个系统有64M内存，它的合法地址范围是从0到0x4000000（以十六进制表示）。每个地址都对应于所安装的SIMMs中的一组晶体管，而且对应于处理器地址总线上的一组特定信号。分页可以在一个进程的生存期里，把它或它的片段移入或者移出不同的物理内存区域（或不同物理地址）。这正是进程被分配一个逻辑地址空间的原因之一。就任何特定的进程来说，从0开始扩展到十六进制地址0xc0000000共3GB的地址空间是绰绰有余的。即使每个进程有相同的逻辑地址空间，相应进程的物理地址也都是不同的，因此它们不会彼此重叠。从内核的角度看来，逻辑和物理地址都被划分成页面。因此，就像我们所说的逻辑和物理地址一样，可以称它们为逻辑和物理页面：每个合法的逻辑地址恰好处于一个逻辑页面中，物理地址也是这样的。与之相反，线性地址通常不被认为是分页的。CPU（实际是下文中的MMU）会以一种体系结构特有的方式把进程使用的逻辑地址转换成线性地址。在x86平台上，这种转换是简单地把虚拟地址与另一地址，即进程的段基址相加；因为每个任务的基址都被设置为0，所以在这种体系结构中，逻辑地址和线性地址是相同的。得到的线性地址接着被转换成物理地址并与系统的RAM直接作用。<H3 13pt 0cm">内存管理单元</H3>在逻辑地址和物理地址之间相互转换的工作是由内核和硬件内存管理单元（MMU—memory management unit）共同完成的。MMU是被集成进现代的CPU里的，它们都是同一块CPU芯片内的一个部分，但是把MMU当作一个独立的部分仍然非常有益。内核告诉MMU如何为每个进程把某逻辑页面映射到某特定物理页面，而MMU在进程提出内存请求时完成实际的转换工作。当地址转换无法完成时，比如，由于给定的逻辑地址不合法或者由于逻辑页面没有对应的物理页面的时候，MMU就给内核发出信号。这种情况称为页面错误（page fault），本章后面会对此进行详细论述。MMU也负责增强内存保护，比如当一个应用程序试图在它的内存中对一个已标明是只读的页面进行写操作时，MMU就会通知OS。MMU的主要好处在于速度。缺少MMU时为了获得同样的效果，OS将不得不使用软件为每个进程的每一次内存引用进行校验，这种校验同时包括数据和指令在内，而这可能还包括要用为进程创建其生存所需的虚拟机。（Java所进行的一些工作与此类似。）这样做的结果将使系统慢得令人无法忍受。但是一个以这种内存访问合法性检查方式集成在计算机硬件里的MMU却根本不会使系统变慢。在MMU建立起一个进程以后，内核就只是偶尔参与工作，例如在发生页面错误时，而这与全部内存引用数量相比是非常少的。除此而外，MMU还可以协助保护内存自身。没有MMU，内核可能不能够防止一个进程非法侵入它自己的内存空间或者是其它进程的内存空间。但是如何避免内核也会作同样的操作呢？在Intel’s 80486或更新的芯片上（不是80386），MMU的内存保护特性也适用于内核进程。<H3 13pt 0cm">页目录和页表</H3>在x86体系结构上，把线性地址（或者逻辑地址——记住在Linux上，这二者具有相同的值）解析（resolving）到物理地址分为两个步骤，整个过程如图8-2所示。提供给进程的线性地址被分为三个部分：一个页目录索引，一个页表索引和一个偏移量。页目录（page directory）是一个指向页表的指针数组，页表（page table）是一个指向页面的指针数组，因此地址解析就是一个跟踪指针链的过程。一个页目录使你能够确定一个页表，继而得到一个页面，然后页面中的偏移量（offset）能够指出该页面里的一个地址。为了进行更详细因而也会更准确的描述：给定页目录索引中的页目录项保存着贮存在物理内存上的一个页表地址；给定页表索引中的页表项保存着物理内存上相应物理页面的基地址；然后线性地址的偏移量加到这个物理地址上形成最终物理页面内的目的地址。其它CPU使用三级转换方法，如图8-3所示。这在64位体系中尤其有用，以Alpha为例，其更大的64位的地址空间意味着类似于x86体系的地址转换将要求大量的页目录、大量页表、大量偏移量，或三者兼有。对于这种情况，Alpha的设计者们向线性地址模式中引入了另一层次，即Linux所称的页面中间目录（page middle directory），它位于页目录和页表之间。这个方案与以前实际是一样的，只不过多增加了一级。这种三级转换方法同样具有页目录，页目录的每一项包含一个页面中间目录的入口地址，页面中间目录的每一项包含一个页表的入口地址，而页表也同以前一样每一项包含物理内存中一个页面的地址，这个地址再加上偏移量就得到了最终的地址。而使情况更为复杂的是，通过进一步观察可知，三部分地址模式与两级地址转换是相关联的，而四部分地址模式则与三级地址转换相关联的，这是由于我们通常所说的“级（或层次levels）”不包括索引到页目录的第一步（我想是因为这一步没有进行转换的缘故）。令人奇怪的是内核开发者们决定只用其中一种模式来处理问题。绝大部分的内核代码对MMU一视同仁，就如同MMU都使用三级转换方法（也就是四部分地址模式）一样。在x86平台上，通过将页面中间目录定义为1，页面相关的宏可以把三级分解过程完美地转换到二级分解过程上去。这些宏认为页面中间目录和页目录是几乎可以进行相互替换的等价品，以至于内核的主要代码可以认为其地址就是由四个部分组成的。在x86系统中，32位地址中10位是页目录索引，接下来10位是页表索引，剩下的12位用作偏移量，这就构成了4K大小的页面（212等于4096个偏移量）。用于创建和操作每一级项的函数和宏定义在头文件include/asm-i386/page.h（第10786行）和include/asm-i386/pgtable.h（第10876行）之中。在读者浏览这些函数和宏的时候，记住PGD通常代表“页目录项（page directory entry）”（不只是“页目录”），PMD通常代表“页面中间目录项（page middle directory entry）”（不只是“页面中间目录”），同样PTE也通常代表“页表项”。而且，正如上面解释中限定词“通常”所暗示的那样，例外是存在的，例如下文将要提到的pte_alloc就分配页表而不是（如你所可能会认为的）页表项。非常遗憾的是，由于篇幅所限我们不能对全部例程进行讨论，我们将在后面对其中的一部分进行讨论。页表项不仅记录了一个页面的基地址，而且记录了它的保护信息（protections），也就是一组指定该页为可读、可写，和/或可执行的标志（这容易让人联想到文件的保护位）。<wrapblock><v:shapetype> <v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path connecttype="rect" gradientshapeok="t" extrusionok="f"></v:path><lock aspectratio="t" v:ext="edit"></lock></v:shapetype><v:shape><v:imagedata></v:imagedata><w:wrap type="topAndBottom"></w:wrap></v:shape></wrapblock> 随着我们对页面保护信息的进一步剖析，读者会看到页表项所包括的其它页面特有的标志。<wrapblock><v:shape><v:imagedata></v:imagedata><w:wrap type="topAndBottom"></w:wrap></v:shape></wrapblock> <H3 13pt 0cm">转换后备缓存（Translation Lookaside Buffers：TLBs)</H3>如果简单的执行从线性地址到物理地址的转换过程，在跟踪指针链时将会需要几个内存引用。RAM虽然不像磁盘那么慢，但是仍然比CPU要慢的多，这样就容易形成性能的瓶颈。为了减少这种开销，最近被执行过的地址转换结果将被存储在MMU的转换后备缓存（translation lookaside buffers：TLBs）内。除了偶尔会通知CPU，由于内核的某操作致使TLBs无效之外，Linux不用明确管理TLBs。在作用于TLB的函数和宏中，我们只研究一下__flush_tlb，在x86平台上，它是其它大部分函数和宏的基础。__flush_tlb10917：CR3（控制寄存器3）是x86CPU寄存器，它保存页目录的基地址。往这个寄存器送入一个值将会使CPU认为TLBs变成无效，甚至写入与CR3已有值相同的值也是这样。 因此，__flush_tlb仅是两条汇编程序指令：它把CR3的值保存在临时变量tmpreg里，然后立刻把tmpreg的值拷贝回CR3中，整个过程就这么简单！ 注意x86系统也允许使某一个单独的TLB项无效，而并不一定非要使全部项，这种方法使用invipg指令——参见第10926行它的使用信息。<H3 13pt 0cm">段</H3>由于段不是在所有CPU中均可用，所以Linux内核中与体系结构无关的部分不能对段进行辨识。在不同的CPU体系中，段的（如果段在体系中是可用的）处理方式大相径庭，这一点是非常重要的。因此，我们在这个问题上不会花费太多时间，不过x86系统上内核使用段的方式还是值得大概讨论一下的。段可以被简单的看作是定义内存区域的另一种机制，有些类似于页。这两种机制可以重叠：地址总是在页面之内，也可能处于段内。与页不同，段的大小可以变化，甚至在其生存期里能够增长和收缩。与页相同的是，段可以被保护，而且其保护可由硬件实施；当x86的段保护和同一地址的页保护发生冲突时，段保护优先。X86系统使用一些寄存器和全局描述表（GDT）和局部描述表（LDT）这两种表来对段进行跟踪。描述符（descriptor）是段的描述信息，它是用来保存段的大小和基址以及段的保护信息的8字节的对象。GDT在系统中只有一个，而Linux可以为每个任务建立一个LDT。接下来我们将简单解释内核是如何使用这些表来建立段的。内核本身拥有分离的代码和数据段，它们被记述在GDT的第2和第3行项里。每个任务也有分离的代码和数据段。当前任务的代码段和数据段不仅在它自己的LDT的第0和第1行项被说明，而且还被记述在GDT的第4和第5行项里。在GDT里，每个任务占两行项，一个用来定位它的LDT，一个用来定位它的TSS（前面章节曾简要提及的任务状态段）。因为x86CPU限制GDT的大小为8192个项，而且Linux为每个任务占用两行GDT项，因此显而易见的是我们不能拥有超过4096个任务，这也正是在第7章里提到的限制。事实上，任务的最大数目要稍小一点儿，不过仍有4090个，这是由于GDT的前12行项被保留用于其它目的。富有经验的x86程序员可能已经注意到Linux所使用的x86分段机制是采用最低限度方式的；段的主要使用目的仅是为了避免用户代码出现在内核段中。Linux更倾向于分页机制。从大的方面来看，对于处理器来说分页或多或少都是相同的，或者说总的事实就是这样，因此内核越是以分页方式工作，它的可移植性就越好。最后要提及的是，如果读者对于x86的分段机制很感兴趣的话，不妨阅读一下Intel体系结构下的软件开发手册第3卷（Intel Architecture Software Developer’s Manual Volume 3），该书可以从Intel站点上免费得到（developer.intel.com/design/pentiumii/manuals/243192. htm）。<H2 13pt 0cm">进程的内存组织</H2>有三个重要的数据结构用于表示进程的内存使用：struct vm_area_struct（第15113行）、struct vm_operations_struct（第15171行），和struct mm_struct（第16270行）。我们随后将对这三个数据结构进行逐一介绍。Struct vm_area_struct内核使用一个或更多的struct vm_area_struct来跟踪进程使用的内存区域，该结构体通常缩写为VMAs。每个VMA代表进程地址空间的一块单独连续的区间。对于一个给定的进程，两个VMAs决不会重叠，一个地址最多被一个VMA所覆盖；进程从未访问过的的一个地址将不会在任何一个VMA中。两个VMA之间的区别有两个特征：l 两个VMA可以不连续（Two VMAs may be discontiguous）——换句话说，一个VMA的末尾不一定是另一个的开头。l 两个VMA的保护模式可以不同（Two VMAs may have different protections）——例如，一个是可写的而另一个可能是不可写的。即使两个这样的VMA是连在一起的，它们也必须被分开管理，因为其不同的保护信息。应注意的一个重点是，一个地址可以被一个VMA所覆盖，即使内核并没有分配一个页面来存贮这个地址。VMA的一个主要应用就是在页面错误时决定如何作出反应。我们可以将VMAS看作是一个进程所占用的内存空间以及这些空间的保护模式的总体视图。内核能够反复重新计算从页表而来的VMA中的大部分信息，不过那样速度会相当慢。进程的所有VMA是以一个排序的双向链表方式存储的，并且它们使用自己的指针来管理该列表。当一个进程有多于avl_min_map_count数目（在第16286行定义为32）的VAM时，内核也会创建一个AVL数来存储它们，此时仍然是使用VMAs自己的指针对该树进行管理。AVL树是一个平衡二叉树结构，因此这种方法在VMA数量巨大时查找效率十分高。不过，即使在AVL树被创建后，线性列表也会被保留以便内核即使不使用递归也能轻松的遍历一个进程的所有VMA。Struct_vm_area_struct的两个最重要的元素是它的vm_start和vm_end成员（分别在第15115行和15116行），它们定义了VMA所覆盖的起止范围，其中vm_start是VMA中的最小地址，而vm_end是比VMA最大地址大一位的地址。在本章后面我们会反复提及这些成员。注意，vm_start和vm_end的类型是unsigned long，而不是读者可能会认为的void*。由于这个原因，内核在所有表示地址的地方都使用unsigned long类型，而不用void*类型。采用这种方法的部分原因是可以避免因内核对诸如比特一级的地址进行计算操作时引起的编译警告，还可能避免由于它们而偶然引起的间接错误。在引用内核空间的一个数据结构的地址时，内核代码使用指针变量；在对用户空间的地址进行操作时，内核却频繁的使用unsigned long——实际上，几乎只有本章中所涉及的代码才是这样。这样就给用来编译内核的编译器提出了要求。使用unsigned long作为地址类型就意味着编译器必须使unsigned long的类型长度和void*的一样，尽管实践中对这一点的要求不是十分严格。对于x86寄存器上的gcc来说，两种类型很自然的都是32位长。在64位指针长度的体系中，比如Alpha，gcc的unsigned long类型长度通常也是64位。尽管如此，在将来的体系结构上，gcc的一个端口可能提供与void*不同的unsigned long类型长度，这是需要内核的移植版本开发人员（kernel porters）注意的一点。还要说明的是，除了gcc之外你不需要对编译器的性能有太多担心，因为其它大部分与gcc相关的特性都已经包括在代码之中了。假如读者试图用某个其它的编译器来编译内核的话，我想有关unsigned long和void*长度的错误将会占编译错误列表的绝大多数。Struct vm_operations_struct一个VMA可能代表一段平常的内存区间，就像是malloc函数所返回的那样。但是它也可以是对应于一个文件、共享内存、交换设备，或是其它特别的对象而建立的一块内存区域；这种对应关系是由本章后面将要涉及的称为mmap的系统调用所确定的。我们不想牵扯太多关于VMA可以被映射的每一种对象的专门知识，这会使对内核代码的剖析变得凌乱不堪，因为那样就不得不反复决定是否要关闭一个文件、分离共享内存等等令人非常头疼的事情。与此不同，对象类型struct vm_operations_struct抽象了各种可能提供给被映射对象的操作，比如打开、关闭之类。一个struct vm_operations_struct结构体就是一组函数指针，它们之中可能会是NULL用来表示一个操作对某个被映射对象是不可用的。举例来说，在一个共享内存没有被映射的情况下，把该共享内存对象的页面与磁盘进行同步是没有意义的，表示共享内存操作的struct vm_operations_struct里的sync成员就是NULL。总之，一旦VMA映射为一个对象，那么它的vm_ops成员就会是一个非空的指针，指向一个表示被映射对象所提供操作的struct vm_operations_struct结构体。对于VMA可以映射的每一种对象类型，都有一个该VMA可能会在某处指向的静态static struct vm _ operations_struct结构体。参见第21809行这样的一个例子。Struct mm_struct一个进程所保留的所有VMA都是由struct mm_struct结构体来管理的。指向这种结构类型的指针在struct task_struct中，确切的说，它就是后者的mm成员。这个成员被前一章中所讨论的goodness（第26388行）应用，来判断是否两个任务是在同一个线程组中。两个具有相同mm成员（正如我们所见到的）的任务管理同一块全局内存区域，这也是线程的一个特点。struct mm_struct结构体的mmap成员（第16271行）就是前述的VMA的链接列表，而它的mmap_avl成员，如果非空，就是VMA的AVL树。读者可以浏览struct mm_struct的定义，会发现它还包括相当多的其它成员，它们中的几个会在本章中涉及到。<H3 13pt 0cm">VMA的操作</H3>本小节介绍后面要用到的find_vma函数，并捎带简介它的同类函数find_vma_prev。这将阐明VMA处理操作的一些方面，也为读者将要接触的代码做准备。find_vma33460：简单说来，find_vma函数的工作就是找到包含某特定地址的第一个VMA。更准确 的说，它的工作是找到其vm_end比给定地址大的第一个VMA，这个地址可能会在该VMA之外，因为它可以比VMA的vm_start要小。这个函数返回指向VMA的指针，如果没有满足要求的VMA就返回NULL。33468：首先，通过使用mm的mmap_cache成员，满足进程最近一次请求的同一VMA会被检查，而mmap_cache正是为此目的而设。我没有亲自测试过，不过这个函数的文档中说高速缓存的命中率可以达到35%，考虑到高速缓存只由一个VMA组成，那么这个数字就相当好了。当然，著名的、被称之为“引用的局部性（locality of reference）”的特性一直在其中提供了很大帮助，这也是软件访问数据（和指令）时的一条原则，即访问最近使用过的数据（和指令）。由于VMA包含一块连续的地址区间，引用的局部性就使得所需的地址都在同一个VMA中变为可能，而这样的VMA就会满足前面的要求。在修改VMA列表的其它几个地方，这个高速缓存的值被设为空，表明对VMA列表所做的修改可能会使它失效。至少在一个这种情况中，第33953行，使该高速缓存为空不总是必要的；这段代码如果能够再聪明一些的话，就可能从本质上改善高速缓存的命中率。33471：高速缓存没有命中。假如没有AVL树，find_vma只是搜索列表上的所有VMA，然后返回第一个符合条件的VMA。回想一下VMA的列表是保持顺序的，所以符合条件的VMA也就是所有符合条件的VMA中地址最小的一个。假如搜索到列表的末尾都没有一个匹配，vma就被置为NULL，并被返回。33476：若有大量VMA，沿树遍历就比沿链表遍历要快；由于AVL树是平衡的，这就是一种对数时间操作而不是线性时间操作。树的迭代遍历并不是十分少见的现象，不过一些特征也并不非常明显。首先注意第33484行的赋值；这个操作一直跟踪当前找到的最好节点，当不能找到更好的时，它就会被返回。接着的下一行中的if语句是一个最优测试，检测addr是否处于VMA中（我们已知的一点是addr小于VMA的vm_end）。因为VMA绝对不会彼此覆盖，没有其它VMA将是一个较贴近的匹配结果，所以树的遍历可以早些结束。33492：如果在树的遍历或列表搜索过程中找到一个VMA，找到的值就被保存在高速缓存里以便下一次查找。33496：在任何情况下，vma都被返回；它的值或者是NULL，或者是满足查找条件的第一个VMA。Find_vma_prev如前所述，这个函数（从第33501行开始）和find_vma函数是一样的，不过它还会额外的返回一个指向前一个限定的addr（如果有）的VMA的指针。这个函数不仅是因为它本身的缘故而令人感兴趣，更主要是由于它的出现会告诉我们一些关于内核程序设计，特别是关于Linux内核程序设计的信息。应用程序员很可能已经在更加通用的find_vma_prev函数之上写出了find_vma函数，这只需简单的把指向VMA的指针去掉即可，代码如下：p504.1应用程序员这样做的原因是具有代表性的应用程序并不太拘于速度因素。这并非纯粹是在为铺张浪费找借口，而是由于CPU速度的不断增加使得应用能够更关注于其它方面，我们现在可以出于可维护性的充分理由而提供一个可以到处使用的额外函数调用。与之相反，一个内核程序员可能不会随便增加多余的函数调用；试着减少几个CPU时钟周期会被认为比负责维护某个近乎是副本的函数要更胜一筹。即使没有其它原因，我们也可以说内核开发者所持有的这种态度就是为了让应用程序员能相对自由一些。为什么这种重复对于源代码相对封闭的操作系统，Linux而言不那么重要，这里是否有更深层次原因呢？尽管Linux内核必须限制它占用的CPU时间，Linux内核的开发工作却不受程序员时间的限制。（明确的说，我必须要指出Linux的开发者不必把他们的时间浪费在会议上的，他们也不必被人工制订的时间表所拘束。）正是由于这众多的队伍，众人的智慧，才改变了软件开发的规则。Linux内核的源代码对任何人都是公开的，Linus本人曾说过的一句名言是“…只要眼睛够多，所有的臭虫（程序错误）都是浅薄的<a href="http://www.madio.net/bbs/dispbbs.asp?boardid=84&id=3190&star=2#_ftn1" target="_blank" >[1]</A>”。就算函数find_vma和find_vma_prev的执行会产生重大差异，在你能想到“重编译”之前，不知什么地方的某个Linux内核开发者就已经迅速发现并修复了这个问题。实际上，Linux内核开发者比它的商业对手动作快得多，所得到的代码运行更快而且错误更少，尽管有时偶然出现的结构会被认为在任何其它环境中都不可维护。当然，如果没有人负责对这些函数的改进进行维护的话，我认为这也是非常愚蠢的。内核的下一个发布版本就把它们合并了。但是我仍然对此持怀疑态度，而且即使我在这个具体问题上所持的态度并不正确，我依然在总体上保持原有态度。 不同的事还会继续不同，而不同正是Linux之所以为Linux的一方面。<H3 13pt 0cm">分页</H3>本章前面对分页已作了概要描述，现在我们进一步来研究Linux是如何处理分页的。<H4 14pt 0cm 14.5pt">页面保护详述</H4>正如早先提及的，页表项不仅保存了一个页面的基地址，还有其它一些标志信息，这些标志指出了该页面上所能进行的操作。现在是仔细研究一下这些标志的时候了。如果页表项只保存一个页面的基地址，并且页面是页对准的（page-aligned），这个地址的低12位（x86系统），即偏移量部分通常将总是为0。取代这些位置0的作法是把它们编码作为与页面有关的标志，在获取地址时只需简单的把它们屏蔽掉就行了。以下就是这12位中的标志位：l _PAGE_PRESENT位（第11092行），若置位，当前页面物理存在于RAM中。l _PAGE_RW位（第11093行），置为0表示该页面是只读的，置为1表示可读可写。因此，没有只写的页面。l _PAGE_USER位（第11094行），置位表示某页面是用户空间页面，清空表示为内核空间页面。l _PAGE_WT位（第11095行），置为1表示页面高速缓存管理策略是透写，置为0表示管理策略是回写。透写（writethrough）会立刻把写入高速缓存的数据复制（拷贝）到主存储器内，即使保存在高速缓存的数据仍是读访问。与之相反，回写（writeback）具有更高的效率，写入高速缓存的数据仅当其必须为其它数据腾出空间，而必须移出时才被复制到主存储器内。（这是由硬件，而不是Linux完成的。）尽管直到本书写作之时，这个标志位在内核中的使用还并不非常普遍，不过这种情形有望很快改变。有时候，Intel公司的处理器资料中把WT位更多的称为PWT。l _PAGE_PCD位（第11096行），关闭页面高速缓存；本书中的代码不总是使用这个标志位。（缩写“CD”表示“caching disabled”。）如果我们恰好知道一个不经常使用的页面，那么就不必为它设置高速缓存，这可能会更有效率。这个标志位好像对于映射内存的I/O设备来说更有用处，尽管我们想确保对表示设备的内存进行的写操作不被高速缓存缓冲，但是取而代之的作法是立刻把数据直接拷贝到设备之中。l _PAGE_ACCESSED位（第11097行），若置位表示该页面最近曾被访问过。Linux可以设置或清除这个标志，不过通常这是由硬件完成的。因为清除了该标志的页面已很久未被使用过，所以它们会在交换时被优先调出主存。l _PAGE_DIRTY位（第11098行），若置位，表明该页面的内容自从上次该位被清除后已发生改变。这就意味着它是一个内容没有保存的页面，就不能简单的为交换而被删除。当一个页面第一次写入内存时，该标志位由MMU或Linux设置；当这个页面调出内存时，Linux要读取它的值。l _PAGE_PROTNONE位（第11103行），是一个以前的页表项没有使用过的标志位，用来跟踪当前页面。_PAGE_4M位和_PAGE_GLOBAL位在同一个#define定义块中出现，但是由于它们不像其它标志位那样用于页面级的保护，所以我们在此不予讨论。随后的文件中，上述这些标志位被组合在一个高级宏内。<H4 14pt 0cm 14.5pt">写拷贝（copy-on-write）</H4>提高效率的一条路就是偷懒——只做最少量的必要工作，而且只在不得不做的时候才完成。现实生活中这可能是个坏习惯，至少它会导致拖拖拉拉。而在计算机的世界里，它可能更是一种优点。写拷贝（Copy-On-Write）就是Linux内核一种通过懒惰来获得效率的方法。其基本思想是把一个页面标记为只读，却把它所含的VMA标识为可写。任何对页面的写操作都会与页级保护相冲突，然后触发一个页面错误。页面错误处理程序会注意到这是由页级保护和VMA的保护不一致而导致的，然后它就会创建一个该页的可写拷贝作为代替。写拷贝十分有用。进程经常fork并立刻exec，这样为fork而复制的进程页面会造成浪费，因为exec之后它们会不得不被抛弃。正如读者所见，进程分配大量内存时也使用同样的机制。所有被分配的页面都与一个单独的空白页面相映射，这就是写拷贝的原意。向某页面的第一次写操作会触发页面错误，然后空白页面执行复制。用这种办法，只有页面分配不能再延期时，它才会被分配。<H4 14pt 0cm 14.5pt">页面错误</H4>到现在为止，本章已几次提到一个页面可以不在RAM里的可能性——毕竟，如果页面总是在内存里，虚拟内存就没什么必要了。但是我们还没有详细介绍过当某页面不在RAM中会怎样。当处理器试图访问一个当前不在RAM中的页面时，MMU就会产生一次页面错误，而内核会尽力解决它。在进程违反页级保护时，页面错误也会产生，例如进程试图向只读内存区域写入。因为任何无效内存访问都会导致页面错误，同样的机制支持请求分页。请求分页（Demand paging）的意思是只有在页面被引用的时候才从磁盘上读取它们——即按需分配——这是另一种通过懒惰来获得效率的方法。特别地，请求分页用于实现被请求页面的可执行化。为了达到这个目的，应用程序第一次被装载时，只有一小部分可执行映象（image）被读入物理内存，然后内核就依靠页面错误来调入需要的（比如，进程首次跳转到一个子例程时）可执行页面。除了一些意外的情况，这样做总是要比把所有部分一次读入要快，这是因为磁盘较慢，而且并不是所有的程序都会用到的。事实上，因为一个大程序运行一次时，大部分功能特性都不会再用到，所以通常根本不需要全部都读入（这一点对大多数中小规模的程序也是成立的）。这对于按需分页（demand-paged）的可执行程序稍有不同——如果你对这种情况进行考虑的话，你就可以知道按需分页还需要二进制处理程序的支持，而且它是一个具有决定意义的部分。Do_page_fault6980： do_page_fault是内核函数，产生页面错误时（在第363行）被调用。当页面错误产生时，CPU调整进程的寄存器，当解决页面错误时，进程再从引起错误的指令处开始执行。通过这种方法，在内核使得冲突地内存访问操作完成后，会自动重试该操作。相反，如果页面错误仍然无法解决，内核就通知引起冲突的进程。当页面错误是由内核本身导致的时候，所采用的措施是近似的，但并不完全相同。6992： 控制寄存器2（CR2）是Intel CPU的寄存器，保存引起页面错误的线性地址。该寄存器内的地址会被直接读入局部变量address。7004：函数find_vma（第33460行）返回地址范围末尾在address之后的第一个VMA。大家知道，这并不能够保证该地址位于VMA的范围内，而仅保证该地址比VMA <DIV footnote-list"> <HR align=left width="33%" SIZE=1><DIV>1 原文为：”…given enough eyeballs, all bugs are shallow.”</DIV></DIV>

我也说一句

发表

1万主题	49 听众	2万积分

TA的每日心情

	奋斗 2024-6-23 05:14

签到天数: 1043 天

[LV.10]以坛为家III

群组: 万里江山

群组: sas讨论小组

群组: C 语言讨论组

群组: Matlab讨论组

12^#

发表于 2005-3-4 22:15 |只看该作者 |招呼Ta 关注Ta

0cm 0cm 0pt">或调度策略。由于这比仅仅的完美级别要更适用，CAP_SYS_NICE是一个误用的位——虽然很容易就可以看出设置调度策略和相关的概念是紧密相关的，而且你一般也不会要一个权能而不要另外一个权能。<

0cm 0cm 0pt">每一个进程都有三个权能，它们被存储在进程的struct task_struct结构中（在16400行到16401行中）：<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l1 level1 lfo2; tab-stops: list 42.25pt">l cap_effective——有效置位集合<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l1 level1 lfo2; tab-stops: list 42.25pt">l cap_permitted——允许位集合<

0cm 0cm 0pt 42.25pt; TEXT-INDENT: -21.25pt; mso-list: l1 level1 lfo2; tab-stops: list 42.25pt">l cap_inheritable——继承位集合<

0cm 0cm 0pt">进程权能的有效位集合是当前可以处理的内容的集合；这是通过广泛使用的capable函数检测的集合，这个函数在16738行定义。<

0cm 0cm 0pt">允许位集合规定进程正常地可以被赋予的权能。这个集合通常不会增加——只有一种情况例外：如果一个进程具有CAP_SETPCAP权能，那么它就可以将自己的允许位集合中的任何权能赋给其它进程，即使目标进程还没有拥有这个权能。<

0cm 0cm 0pt">如果一个权能在允许位集合中，但是并不在有效位集合中，那么进程现在还没有马上拥有权能，但是它可以通过请求权能而获得。为什么要麻烦地区别它们呢？在本章开始我们第一次讨论权能的时候，我们简单地考虑了一个简单的例子：一个长期运行的进程只是偶然需要权能，而不是所有情况下都需要。为了保证进程不会偶然缺少权能，进程可以一直等待，直到它需要权能，接着请求权能，执行有权限的操作，并再次取消权能。这种方法比较安全。<

0cm 0cm 0pt">继承位集合不像你想象的那么简单。它不是祖先继承在执行fork的同时传递的权能集合——实际上，在创建的那一刻（也就是紧随着fork），子孙进程的权能的三个集合和其祖先的三个权能集合都是相同的。相反，继承位集合在exec运行期间才会起作用。进程在调用exec之前的继承位集合有助于决定它的允许位集合和继承位集合，它们在exec执行结束以后也会保留下来——仔细的介绍请参看compute_creds（9948行）。注意在exec之后权能是否保留要部分依赖于进程的继承位集合；它还要部分依赖于文件本身中的权能位集合（或者不管怎样，这至少是一个计划——虽然这种特性还没有完全实现）。<

0cm 0cm 0pt">顺便提一下，注意到允许位集合必须总是有效位集合和继承位集合的超集（superset）（或者和有效位集合相同）。（只有对于有效位集合这才是严格正确的。一个进程可能会扩展另外一个进程的继承位集合从而它不再是其允许位集合的子集，但是就我知道的来说，这是无意义的，因此我们从现在就开始忽略这种可能性。）然而，和你可能希望的相反，有效位集合不一定要是继承位集合的超集（或者和继承位集合相同）。也就是说，在exec结束以后，进程可能会拥有一个以前不曾有过的权能（虽然这个权能必须在其允许位集合中——也就是说，这是一个原来进程自己可能已经得到了的权能）。我认为这种需要只是局部的，这样进程就不需要暂时获得不需要的权能，而能够获得足以执行exec程序的权能。<

0cm 0cm 0pt"> <

0cm 0cm 0pt"><wrapblock><v:shapetype><v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path connecttype="rect" gradientshapeok="t" extrusionok="f"></v:path><lock aspectratio="t" v:ext="edit"></lock></v:shapetype><v:shape><v:imagedata></v:imagedata><w:wrap type="topAndBottom"></w:wrap></v:shape></wrapblock> <

0cm 0cm 0pt; TEXT-ALIGN: center; mso-outline-level: 1" align=center>图7.4 权能集<

0cm 0cm 0pt; TEXT-ALIGN: center; mso-outline-level: 1" align=center> <

0cm 0cm 0pt">图7.4说明了各种可能性。它显示了一个理想进程的三种权能集合，位从左到右计数。允许进程可以获得CAP_KILL权能，这样就允许它不考虑其它属主而杀掉别的进程，但是它还没有立即拥有权限，而且也不会在exec执行过程中自动获得。目前它具有增加和删除内核模块的权能（使用CAP_SYS_MODULE），但是同样也不会在exec执行过程中自动获得。它可以获得CAP_SYS_NICE权能，但是直到exec执行完后才会获得（假定文件权能位允许）。最后，它可以立即修改系统时间（CAP_SYS_TIME），但是也是只有通过exec才能获得这个权能。除非其它具有CAP_SETPCAP权能的进程提供了这个权能，否则这个进程不能获得这个权能，它可能执行的其它进程也不可能获得这个权能。<

0cm 0cm 0pt">保证这些不同性质的代码主要是在kernel/capability.c中，从22460行开始。两个主要的函数是读取权能的函数sys_capget（22480行）和设置权能的函数sys_capset（22592行）；它们在下一节中讨论。通过exec继承的权能使用fs/exec.c的compute_creds（9948行）处理，这一点已经介绍过了。<

0cm 0cm 0pt">当然，root肯定拥有所有的权能。内核权能特性给root提供了一种规则的方法来有所选择地只把需要的权能赋给特定的进程，而不用考虑该进程是否作为root用户运行。<

0cm 0cm 0pt">权能一个有趣的特性是它们可以用来改变系统的“风格”。作为一个简单的例子，为所有的进程设置CAP_SYS_NICE权能会使所有进程都增加自己的优先级（并设置它们的调度规则，等等）。如果你修改了系统中每一个进程的运行方式，那么你就改变了系统本身。自己设想一下发明一种新的可以通过更令人兴奋的方式修补系统的内核权能。<

0cm 0cm 0pt">权能的尚未为人所知的优点是它们使源程序代码非常清晰。当检测当前进程是否允许设置系统时间时，却反而要检测当前进程是否以root运行，这种方式看起来似乎有些不很好。权能使我们可以了解它们的意思。权能的存在甚至还能够使查询进程的用户ID或组ID的代码更为清晰，这是因为这样的处理代码对这个问题的答案比较感兴趣，而是对从其中可以推导出的结论更感兴趣。否则，代码应该已经使用权能查询它需要了解的内容了。由于权能更加一致地和Linux内核代码结合起来，这种特性就变得更加可靠了。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">13916：内核可以识别的权能从这里开始。因为这些宏定义的解释已非常详细了，我们就不再详细介绍其中每一个的内容了。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">14153：赋给每一个权能的数字是简单的连续整数，但是由于要使用无符号整数中的位来编址，所以就使用CAP_TO_MASK宏把它们转化为2的幂。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">14154：设置和检测权能的核心只是一系列位操作；从这里到include/linux/capability.h中定义了用来使位操作更为清晰的宏和内联函数。<H4 6pt 0cm; TEXT-INDENT: 0cm">sys_capget</H4><

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">22480：sys_capget有两个参数：header和dataptr。header是cap_user_header_t类型（13878行）的，它是一个指向定义权能使用的版本和目标进程的

ID的结构的指针；dataptr是cap_user_data_t类型（13884行）的，它也是一个指向结构类型的指针——这个结构包含有效位、允许位和继承位集合。sys_capget通过第二个指针返回信息。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">22492：在版本不匹配的情况下，sys_capget通过header指针返回使用的版本，接着返回EINVAL错误（或者如果它不能把版本信息拷贝到调用者的空间中就返回EFAULT）。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">22509：定义调用者希望了解其权能的进程；如果pid不是0，也不是当前进程的

ID，sys_capget就要查询它。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">22520：如果它能装载目标进程，它就把自己的权能拷贝到临时变量data中。<

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">22530：如果所有工作到目前为止都运行良好，它就把权能拷贝回用户空间中由dataptr参数提供的地址中。然后，它返回error变量——通常如果一切运行良好，这就是0；否则就是一个错误号。<H4 6pt 0cm; TEXT-INDENT: 0cm">sys_capset</H4><

0cm 0cm 0pt 36pt; TEXT-INDENT: -36pt">22592：sys_capset的参数几乎和sys_capget的参数类似。不同之处是data（不再称为dataptr了）是常量。22600：和sys_capget一样，sys_capset确保内核和调用进程使用一致的权能系统的版本。如果版本不一致，就拒绝尝试请求。22613：如果pid不是0，就说明调用者希望设置其它进程的权能，在大多数情况下这种尝试都会遭到拒绝。如果调用者具有CAP_SETPCAP权能，这意味着允许它设置任何进程的权能，sys_capset就允许这种尝试。这种测试的前面部分有些太受限制了：如果它和当前进程的pid相等，就接收这个pid。22616：从用户空间中拷贝新的权能，如果失败就返回错误。22627：和22509行开始的sys_capget代码类似，sys_capset定义了调用者希望了解其权能的进程。这就是两者的区别所在，sys_capset为了说明进程组（或者是-1指明是所有进程）也允许其pid值为负。在这种情况下，target仍然设置为current，因此当前进程的权能要在后面的计算中使用。22642：现在它必须保证合法地使用新的权能位集合，而且在内部保持一致。除非这种新特性在调用者的允许位集合中，否则这种测试会验证出新进程的继承位集合没有包含任何新鲜的东西。因此，它不会放弃调用者尚未拥有的任何权能。22650：类似地，sys_capset也要确保除非调用者的允许位中包含新的特性，否则目标进程的允许位集合也不会包含尚未具有的特性。因此，它也不会放弃调用者尚未拥有的任何权能。22658：回想一下进程的有效位集合必须是其允许位集合的一个子集。这种性质在这里得到了保证。22666：sys_capset现在已经准备对请求做出修改。负的pid值意味着它正在给不止一个进程修改权能——如果pid是-1，就是所有的进程；如果pid是其它的负值，就是一个进程组中的所有进程。在这些情况下，实际工作分别由cap_set_all（22561行）和cap_set_pg（22539行）完成；这只是通过一些适当的进程集合循环，按照和单个进程相同的方法覆盖掉集合中的每一个进程的权能位集合。22676：如果pid是正数（或者是0，表示当前进程），权能位集合只赋给目标进程。<H3 6pt 0cm; TEXT-INDENT: 0cm">用户ID和组ID</H3>尽管权能功能强大、十分有用，但它并不是你实现访问控制的唯一武器。在一些情况中，我们需要了解哪个用户正在运行一个进程，或者进程是作为哪个用户来运行。用户使用整型的用户ID来区别，一个用户可以属于一个组或者多个组，每一个都有自己特有的整型ID。有两种风格的用户ID和组ID：实际的ID和有效的ID。一般说来，实际用户（或组）ID为你说明了哪个用户创建了进程，有效用户（或组）ID为你说明在情况改变时进程作为哪个用户运行。由于访问控制的决定要更多依赖于进程作为哪儿用户运行，而不是哪个用户创建了这个进程，因此内核会比检测实际用户（和组）ID更加频繁地检测有效用户（或）ID——在我们现在关心的代码中就是这样处理的。struct task_struct结构中的相关成员是uid，euid，gid，和egid（16396行到16397行）。注意用户ID和用户名不同，前者是一个整数，而后者是一个字符串。/etc/passwd文件把这两者关联起来。让我们再回到sys_setpriority并看一下前面我们忽略了的从29244行到29245行的一些代码。sys_setpriority通常执行的操作都是让用户降低自己进程的优先级，但是不能降低其它用户进程的优先级——除非用户具有CAP_SYS_NICE权能。因此，if表达式的前面两个术语要检测目标进程的用户ID是否和sys_setpriority的调用者的实际用户ID或者有效用户ID匹配。如果两个都不匹配，并且SYS_CAP_NICE没有设置，sys_setpriority就正确地拒绝这种尝试。如果允许，进程可以使用sys_setuid和sys_setgid（29578行和29445行）和其它一些函数修改它们的用户ID和组ID。用户ID和组ID也可以通过执行可执行的setuid或setgid可执行程序进行修改。<H3 6pt 0cm; TEXT-INDENT: 0cm">资源限制</H3>可以要求内核限制一个进程使用系统中的各种资源，包括内存和CPU时间。这可以通过sys_setrlimit实现（30057行）。通过浏览struct rusage结构（16068行）你对支持限制就可以有一个基本的概念。进程特有的限制在struct task_struct结构中记录——还可能在什么地方？请参看16404行的rlim数组成员。违反限制的结果根据限制的不同也会有所不同。例如，对于RLIMIT_MPROC（在本书的源程序代码中没有包括）——有关一个用户可以拥有的进程数目的限制——和你在23974行中看到的一样，结果仅仅和fork失败一样。超出其它限制的后果对于一些进程可能比较严重，这样进程会被杀死（请参看27333行）。进程可以使用sys_getrlimit（30046行）请求特殊限制，或者使用sys_getrusage（30143行）请求资源使用限制。在30067行中，注意进程可以随意减少自己的资源限制，但是它增加自己的资源限制时只能增加到一个最大值，这个值可以根据每一个资源限制进行具体设置。因此，当前的资源限制和所有的资源限制是分别记录的（使用在16089行定义的struct rlimit结构的rlin_cur成员和rlim_max成员）。然而具有CAP_SYS_RESOURCE权能的进程可以覆盖这个最大值。这和优先级的规则不同：允许进程可以减小自己的优先级，但是为增加其优先级需要特殊许可，即使是它减少了自己的优先级接着又要马上增加它也是如此。当前资源限制和最大资源限制这两个相互关联的概念并没有反映在内核优先级的调度中。还有，注意到一个进程可以改变另一个进程的优先级（当然是假定它有权这样处理），但是一个进程只能修改自己的资源限制。<H2 13pt 0cm; TEXT-INDENT: 0cm">所有美好的事物都会结束——这就是它们如何处理的</H2>我们已经看到进程是如何生成的，怎样给它们赋予各自的生存周期。现在我们应该看一下它们是如何消亡的。<H3 6pt 0cm; TEXT-INDENT: 0cm">exit</H3>同第6章中介绍的一样，你可以通过给进程发送信号量9强行杀掉进程，但是更普通的情况是进程自动退出。进程通过调用系统调用exit自动退出，它在内核中是由sys_exit实现的（23322行）。（顺便说一下，当C程序从它的main部分返回时，就会潜在调用exit。）当进程退出时，内核释放所有分配给这个进程的资源——内存、文件，等等——当然，还要停止给它继续使用CPU的机会。然而内核不能立即回收代表进程的struct task_struct结构，这是因为该进程的祖先必须能够使用wait系统调用查询其子孙进程的退出状态。wait返回它检测出的死亡状态的进程的PID，因此如果死亡的子孙进程在祖先进程仍在等待时就已经重新分配了，那么应用程序就会被搞乱（和其它问题一样，同一个祖先结束时可以有两个具有相同PID的子孙进程——一个进程是活动的，另一个进程是死亡的——祖先进程也不知道哪一个已经退出了）。因此，内核必须保留死亡子孙进程的PID直到wait发生为止——这通过完整地保持其struct task_struct结构来自动实现的；分配PID的代码就不用再查询它在任务列表中发现的进程是否是活动的。处于这种在两种状态之间的进程——它既不是活动的，也没有真正死亡——被称为僵进程（zombies）。那么sys_exit的任务就是把活动进程转化为僵进程。sys_exit本身的工作很少；它只是简单地把现存退出代码转化为do_exit希望的格式，接着就会调用do_exit，由它来处理实际的工作。（do_exit也会作为发送信号量的一部分来调用，这一点我们在第6章中已经讨论过了。）23267：do_exit把退出代码作为参数处理，在其返回类型之前使用特殊符号NORET_TYPE。虽然现在NORET_TYPE（14955行）定义为空——因此它也就不起作用——但是原来它经常被定义为__volatile__，用来提示gcc该函数不会返回。了解了这一点知识，gcc就执行一些额外的优化工作并取消有关函数不能成功返回的警告信息。使用其新的定义，NORET_TYPE对于编译器就没有用处了，但是它仍然给我们人类传递了很多有用的信息。23285：释放它的信号量和其它System V IPC结构，这一点我们将在第9章中介绍。23286：释放分配给它的内存，这一点我们在第8章中介绍。23290：释放分配给它的文件，很快就会讨论。23291：释放它的文件系统数据，它超出了本书的范围。23292：释放它的信号量处理程序表，这一点我们在第6章中介绍过了。23294：剩下的任务是进入TASK_ZOMBIE状态，其退出代码被记录下来以供将来祖先进程使用。23296：调用exit_notify（23198行），它会警告当前退出任务的祖先进程和其进程组中的所有成员该进程正在退出。23304：调用schedule（26686行）释放CPU。这个对于schedule的调用从来不会返回，这是因为它跳转到下一个进程的上下文，从来不会再跳转回来，因此这是现在退出的进程的最后一次拥有CPU的机会。<H4 6pt 0cm; TEXT-INDENT: 0cm">__exit_files</H4>进程如何和文件交互不是本书的主题。但是我们应该快速浏览一下__exit_files（23109行），因为这样会有助于我们理解__clone函数，这个函数使祖先进程和子孙进程可以共享特定的信息。祖先进程和子孙进程可以共享的一种信息是它们打开的文件列表。和当时说明的一样，Linux使用引用计数器规则来保证进程退出之后可以正确地处理扫尾工作。这里就有个扫尾工作的很好的例子。23115：假设进程已经打开了文件（几乎总会是这样的），__exit_files会递减原来存储在tsk->files->count中的引用计数器。诸如atomic_dec_and_test之类的原子操作将在第10章详细介绍；知道atomic_dec_and_test（10249行）递减其参数值并当参数新值是0时返回真值就足够了。因此，如果tsk的对于目标struct files_struct结构的引用是最后一次时，这就是正确的。（如果这是一个私有拷贝，没有和其它任何进程共享，那么引用计数器的初始值就是1，当然它被减小为0。）23116：在释放记录进程的打开文件的内存之前，必须把这些文件都关闭，这是通过调用close_files（23081行）实现的。23118：释放保留进程的文件描述符数组fd的内存，这个数组是files的一个子域。打开文件（NR_OPEN，在15067行中定义1,024）的最大数量要加以选择，这样本行中的if测试就能正确——fd数组必须刚好适合一个内存页的大小。这样做可以使得内存的分配（或释放）速度快许多；否则，__exit_files只好使用更通用但是速度却慢得多的内核的内存函数了。下一章会加深你对这种决策的理解。23122：最后，__exit_files释放files本身。其它__exit_xxx函数背后的概念是类似的：它们减少了任务自有的对于潜在共享信息的引用计数器，如果这是最后一次引用，它们要负责执行所有必须的工作来将其清除。<H3 6pt 0cm; TEXT-INDENT: 0cm">wait</H3>和exec一样，wait是一组函数，而不是一个函数。（但是和exec不同，wait家族的函数实际包含一个名为wait的函数。）wait家族中的其它函数最终都是使用一个系统调用sys_wait4（23327行）实现的，这个系统调用的名字反映出它实现了wait家族中最通用的函数wait4。标准C库libc的实现必须重新组织对于其它wait函数调用的参数并调用sys_wait4。（这还不是问题的全部：由于历史的原因，内核到Alpha的移植也会提供sys_waitpid。但是即使是sys_waitpid也会反过来调用sys_wait4。）除了处理一些其它内容，sys_wait4——也只有sys_wait4——最终把僵进程送进坟墓。然而从应用程序的观点来看，wait和相关函数要检测子孙进程的状态：检测是否有进程死亡了，如果有，到底是哪一个进程，这个进程是怎样死亡的。<H4 6pt 0cm; TEXT-INDENT: 0cm">sys_wait4</H4>23327：为了适合作为相当通用的一个函数，sys_wait4有很多参数，其中一些是可选的。和通常情况一样，pid是目标进程的PID；和你看到的一样，0和负值是特殊的。如果stat_addr非空，那么它就是所得子孙进程的退出状态应该拷贝到的地址。options是一些可能定义sys_wait4的操作的标志的集合。如果ru非空，那么它就是所获得的子孙进程资源使用信息所应该拷贝到的地址。23335：如果提供了无效选项，sys_wait4就返回错误代码。这种决定看起来有点荒唐；我们可以简单忽略一些无关选项。当然，这样处理所需要的参数，如果调用者设置了自己不想设置的位，那么希望的操作是不要执行——在任何情况下，这都意味着调用者不能正确理解，在这种情况下发送一个失败信号量要比简单地忽略调用者的这种困惑要更多。23342：循环遍历该进程的直接子进程（但不包括其孙进程，曾孙进程，等等）。如同本章中前面说明的一样，进程的最年轻（最近创建的）子孙进程通过struct task_struct结构的p_cptr成员是可访问的，这个最年轻进程原来的兄弟进程通过其p_osptr成员也是可以访问的；因此，sys_wait4从这个最年轻子孙进程开始遍历其祖先的所有子孙进程，并逐渐遍历其原来的兄弟进程。23343：根据pid参数的值筛选出不匹配的PID。注意值为-1的pid参数是如何潜在的对进程进行选择的，正如我们所期望的：pid值在23343，23346和23349行中的测试没有成功，因此它就不会遭到拒绝。这样，系统需要对每一个子孙进程进行考虑。23376：这就是我们现在感兴趣的情况——祖先进程正在等待一个已经结束了的进程。这是最后实际上得到僵进程的地方。它通过更新子孙进程使用的进程的用户时间和系统时间部分开始（这通过29772行的sys_times系统调用实现），因为子孙进程不会再参与计算了。23382：其它资源使用信息被收集起来（如果要求这样处理），子孙进程的退出状态被传递到特定的地址中（同样，如果要求这样处理）。23387：设置retval为当前得到的死亡子孙进程的PID。这就是最后的结果；retval不会再改变了。23388：如果这个垂死进程的当前祖先进程不是原来的祖先进程，那么进程就会离开进程图表中的当前位置（通过REMOVE_LINKS，16876行），在其原始祖先的控制下重新安装自己（通过SET_LINKS，16887行），接着给其祖先进程发送SIGCHLD信号量，这样祖先进程就知道其子孙进程已经退出了。这种通知是通过notify_parent（28548行，在第6章中介绍）传递的。23396：否则——正常情况——最后可以调用release（22951行）释放所得子孙进程的struct task_struct结构。（在看完sys_wait4以后，我们马上就会看release。）23400：现在已经成功获取了子孙进程，因此sys_wait4只需要返回成功信息就完美地完成了工作；它跳转到23418行，从这儿返回retval（所获得子孙进程的PID）。23401：注意特殊的流程控制；default的情况需要继续执行从23342行开始的for循环。因为只有既没有停止运行也不是僵进程的进程才会执行到default的情况，所以这种流程控制是正确的，但是初次阅读时比较容易误解。而且，无论如何这也有些多余；没有它循环也一样能处理。23406：如果代码能运行到此处，for循环就可以完整地运行下来——正在调用的进程遍历执行其子孙进程没有发现匹配的整个列表——计算的结果是三种状态中的一种。或者由于该任务没有和所提供的pid参数匹配的子孙进程，因而还没有进程退出，或者（是前面情况的一个特例）该任务根本就没有子孙进程。23408：如果flag不为0，在for循环中就可以执行到23358行，这说明至少有一个进程和所提供的pid参数匹配——它不是僵进程，也没有被终止，因此它就不能被获取。在这种情况下，如果提供了WNOHANG选项——这意味着如果不能获取子孙进程，那么调用者就不会等待——它向前跳转到最后，返回0。23411：如果有信号量被接收，就退出并返回一个错误。这个信号量不是SIGCHLD——如果它是SIGCHLD，就应该已经发现了死亡的进程，因此就不可能执行到此处。23413：否则，一切都没有问题；调用者只需要等待一个子孙进程退出。因此，进程的状态被设置为TASK_INTERRUPTIBLE并调用schedule释放CPU给另一个进程使用。正在等待的进程直到再次获得CPU时才会返回，同时要再次检测死亡子孙进程（通过向回跳转到23339行的repeat标号）。回想一下处于TASK_INTERRUPTIBLE状态的进程要等待信号量将其唤醒——在这种情况下，它特别希望SIGCHLD来指明子孙进程已经退出了，但是任何信号量都可以到达。23417：flag是0，因为或者进程没有子孙进程，或者所提供的pid参数不能和它的任何子孙进程匹配——不管怎样，sys_wait4都给调用者返回一个ECHILD错误。<H4 6pt 0cm; TEXT-INDENT: 0cm">release</H4>22951：release的唯一一个参数是指向要释放的struct task_struct结构的指针。22953：确保该任务没有试图释放自身——这是会在内核中引起逻辑错误的一种无意义的情况。22969：UP代码实际上是通过调用free_uid（23532行）开始的，它用来释放潜在共享的struct user_struct结构，这个结构除了其它功能以外，还要帮助fork确保不会出现单个用户影响所有进程的情况。22970：减小系统关于正在运行的任务总数的计数并释放tarray_freelist中的僵死进程的时间片。22974：僵死进程的PID也会释放，并且使用REMOVE_LINKS（16876行）解除它同进程表和任务列表的关联。注意，由于内核数据结构在此处正在做出修正，task数组中的进程项并不需要被设置为NULL；把它的空槽增加到自由列表中就足够了。22979：僵死进程有关次要页表错误，主要页表错误的总数以及向外交换所使用的时间的数量被增加到当前进程对应的 “子孙进程计数”中——这是正确的；release只能通过sys_wait4调用，这样只允许进程释放自己的子孙进程。因此，当前进程必须是僵死进程的祖先。22982：最后，应该回收垂死进程的struct task_struct结构，这可以通过对free_task_struct的调用（2391行）来实现。这个函数简单地回收存储在这个结构中的内存页。现在，进程最终功德圆满的寿终正寝了。

我也说一句

发表

1万主题	49 听众	2万积分

TA的每日心情

	奋斗 2024-6-23 05:14

签到天数: 1043 天

[LV.10]以坛为家III

群组: 万里江山

群组: sas讨论小组