內(nèi)核測(cè)試的現(xiàn)狀

新的內(nèi)核總是會(huì)定期發(fā)布出來(lái)，但是其實(shí)大家并不是十分了解內(nèi)核是如何被深入測(cè)試的。那么這里可以提前告訴大家，內(nèi)核主干有可能并沒(méi)有做過(guò)充分的測(cè)試，而穩(wěn)定內(nèi)核可能會(huì)更少。。。 So what is going on there? Is stable kernel really stable? 剛好今年9月在洛杉磯舉辦的《Linux Plumbers Conference》有一個(gè)BOF(birds of a feather)會(huì)議，Dhaval Ginal和Sasha Levin組織了一個(gè)關(guān)于內(nèi)核測(cè)試的相關(guān)討論，讓我們一起去看看。

[[253592]]

由于大部分BoF的參會(huì)人員來(lái)自各個(gè)主要的Linux發(fā)行商，所以Giani開(kāi)場(chǎng)的時(shí)候提了一個(gè)問(wèn)題：“大家對(duì)于穩(wěn)定內(nèi)核(stable kernels)都做過(guò)了多少測(cè)試呢?大家是不是都是僅僅測(cè)試自己發(fā)行的內(nèi)核然后再?gòu)姆€(wěn)定內(nèi)核中backport一些安全以及其他相關(guān)的修復(fù)呢?對(duì)于穩(wěn)定內(nèi)核的測(cè)試從來(lái)都是置之不理呢?“ 對(duì)于這個(gè)問(wèn)題的答案么，他自己半開(kāi)玩笑的建議：可以將測(cè)試留給了用戶。除了上面這個(gè)半開(kāi)玩笑的建議以外，大多數(shù)人都一致認(rèn)為：目前對(duì)于穩(wěn)定內(nèi)核，除了簡(jiǎn)單的構(gòu)建-啟動(dòng)測(cè)試以外，幾乎很少有其他方面的測(cè)試。那么這個(gè)現(xiàn)象是如何造成的呢?

內(nèi)核測(cè)試的困境

***點(diǎn)：開(kāi)發(fā)者很難知道該去選擇什么樣的上游內(nèi)核(upstream kernel)來(lái)測(cè)試。linux-next tree和穩(wěn)定內(nèi)核以及內(nèi)核主線(mainline)都是在不斷地變化著，要想做到穩(wěn)定測(cè)試是一件很難的事情。但是大家又都一致同意，能在代碼發(fā)布出來(lái)之前，發(fā)現(xiàn)其中的BUG還是很有價(jià)值的，所以一些發(fā)行版的研發(fā)人員就嘗試測(cè)試-rc1的內(nèi)核。這樣做的話，如果bug被發(fā)現(xiàn)，它們將在發(fā)布前就被修正，這樣看起來(lái)是不錯(cuò)的，但是這樣需要非常多的時(shí)間和機(jī)器去做好這件事。另外，測(cè)試時(shí)使用的哪個(gè)版本的內(nèi)核配置，也會(huì)使這個(gè)問(wèn)題的復(fù)雜度翻倍。

第二點(diǎn)：內(nèi)核測(cè)試消耗大量的人力物力。有人舉了一個(gè)生動(dòng)的例子，紅帽(RedHat)需要花費(fèi)一年的時(shí)間去穩(wěn)定RHEL選定的內(nèi)核版本。而粗略估計(jì)有300個(gè)工程師去做這個(gè)事情，這也就是意味著一個(gè)公司需要花費(fèi)了300個(gè)人年去測(cè)試和穩(wěn)固一個(gè)內(nèi)核(譯者在此處還是要感謝一下REDHAT)。此外，在驅(qū)動(dòng)程序中，通常驅(qū)動(dòng)的自檢程序是應(yīng)該由內(nèi)核開(kāi)發(fā)人員編寫(xiě)，但將個(gè)人的測(cè)試變成可以更廣泛使用的東西需要很多時(shí)間和精力，而驅(qū)動(dòng)的作者根本沒(méi)有時(shí)間去添加一個(gè)自檢程序，所以驅(qū)動(dòng)大多數(shù)是沒(méi)有自檢程序的。在許多情況下，正是由于這個(gè)原因，導(dǎo)致代碼質(zhì)量很差。因此，現(xiàn)有的大部分自檢程序可能都是在子系統(tǒng)中并已經(jīng)做了很好測(cè)試，這些測(cè)試用例還能發(fā)現(xiàn)的大部分的錯(cuò)誤主要發(fā)生在與開(kāi)發(fā)者自己運(yùn)行的硬件架構(gòu)不同有關(guān)，比如ARM相關(guān)的錯(cuò)誤就是這樣被發(fā)現(xiàn)的。

第三點(diǎn)：?jiǎn)?dòng)測(cè)試(boot testing)占了上游內(nèi)核測(cè)試的大頭，占據(jù)了開(kāi)發(fā)者更多的精力，所以***發(fā)布的內(nèi)核肯定可以啟動(dòng)起來(lái)的。擁有特殊硬件的人會(huì)測(cè)試他們的驅(qū)動(dòng)，所以通過(guò)這一測(cè)試也可以發(fā)現(xiàn)大部分驅(qū)動(dòng)的bug。像Ftrace、調(diào)度器和內(nèi)存管理由于使用的很廣泛，所以他們的測(cè)試也比較充分。除了以上這些組件以外，內(nèi)核中其他的一些非核心或者不是被普遍使用的功能就可能沒(méi)有那么多的功能測(cè)試了。

第四點(diǎn)：內(nèi)核測(cè)試門(mén)檻較高，如環(huán)境設(shè)備和知識(shí)儲(chǔ)備。對(duì)于一些想要測(cè)試驅(qū)動(dòng)程序的人來(lái)說(shuō)，他可能沒(méi)法獲得相應(yīng)的硬件，即使有硬件，他還需要深入了解設(shè)備是如何工作的。理想情況下，驅(qū)動(dòng)程序的作者應(yīng)該測(cè)試這些設(shè)備，而大部分情況下也確實(shí)是這樣。不過(guò)這個(gè)解決方案仍然不是***的。

第五點(diǎn)：測(cè)試覆蓋不全面，測(cè)試方面單一。因?yàn)殡m然驅(qū)動(dòng)作者試圖確保在他的測(cè)試用例下驅(qū)動(dòng)程序是正確工作的，但是他們有著不同的動(dòng)機(jī)，如果他被雇傭做這個(gè)事情那么可能測(cè)試會(huì)比較全面，而如果他僅僅是為了讓他自己的硬件可以正常工作，那么可能測(cè)試不會(huì)太全面，同時(shí)相應(yīng)的文檔也基本沒(méi)有。

第六點(diǎn)：需要制定測(cè)試指南和幫助文檔。例如，在內(nèi)核測(cè)試中我們還需要發(fā)現(xiàn)一些可能引入的性能退化(performance regressions)，但是如果僅僅是做一些”隨機(jī)性能測(cè)試“(random performance testing)，這是很難發(fā)現(xiàn)性能退化的，因此我們需要制定一些性能測(cè)試指南，以便可以進(jìn)行一些蘋(píng)果對(duì)蘋(píng)果(apples-to-apples，譯為同類(lèi)型的比較)的對(duì)比測(cè)試。再如，就像Mel Gorman的MMTests作為“kbench”這一性能測(cè)試套件的基礎(chǔ)，貌似有些與會(huì)者對(duì)這個(gè)測(cè)試套件不熟悉，所以MMTests需要有更好的文檔來(lái)幫助使用者去了解它。

第七點(diǎn)：進(jìn)行內(nèi)核測(cè)試的另一個(gè)困難是要內(nèi)核配置的數(shù)量非常龐大。當(dāng)穩(wěn)定的內(nèi)核被發(fā)布的時(shí)候，它可能有100個(gè)補(bǔ)丁，但任何測(cè)試套件都不可能執(zhí)行許多次去測(cè)試這些補(bǔ)丁，那么測(cè)試穩(wěn)定版本的意義到底是什么呢?

總結(jié)一下，在所有的這些測(cè)試工作中，***問(wèn)題就是資源，我們需要更多的人和更多的機(jī)器，從而可以更早地發(fā)現(xiàn)和修復(fù)錯(cuò)誤。

企業(yè)是如何做的

我們?cè)侔言掝}切回到穩(wěn)定內(nèi)核。如果我們可以阻止所有可能的bug引入到內(nèi)核，那么主線內(nèi)核(mainline)無(wú)疑是***的，我們也就不需要什么穩(wěn)定分支了(stable trees)。當(dāng)然現(xiàn)實(shí)是殘酷的，***也是不可能的，所以我們?nèi)匀恍枰€(wěn)定分支，但是發(fā)行版真的會(huì)使用穩(wěn)定分支么?讓我們一個(gè)一個(gè)看過(guò)去。

企業(yè)例子之一(紅帽)

紅帽有一個(gè)大型測(cè)試實(shí)驗(yàn)室，有6000多臺(tái)各種各樣的機(jī)器分布在世界各地。實(shí)驗(yàn)室使用Beaker并測(cè)試了大量不同的內(nèi)核配置，目前內(nèi)核測(cè)試主要集中在三個(gè)RHEL內(nèi)核和兩個(gè)Fedora內(nèi)核上，未來(lái)他們會(huì)計(jì)劃添加一些主線版本的內(nèi)核。在紅帽內(nèi)部，不同的團(tuán)隊(duì)專(zhuān)注于他們感興趣的驅(qū)動(dòng)，比如存儲(chǔ)團(tuán)隊(duì)在測(cè)試各種存儲(chǔ)設(shè)備，而RDMA團(tuán)隊(duì)在測(cè)試RDMA類(lèi)型的硬件。所以，對(duì)于紅帽而言，他們只從穩(wěn)定的樹(shù)上去挑選(cherry-pick)一些修復(fù)的補(bǔ)丁。 RHEL的每個(gè)小版本內(nèi)核都有8-10萬(wàn)個(gè)補(bǔ)丁，但是所有的這些補(bǔ)丁都來(lái)自上游而不是穩(wěn)定分支。RHEL內(nèi)核團(tuán)隊(duì)會(huì)查看穩(wěn)定的分支和***的主線內(nèi)核，然后尋找有必要使用的補(bǔ)丁。至于對(duì)應(yīng)的測(cè)試則取決于這些補(bǔ)丁是應(yīng)用于哪一個(gè)子系統(tǒng); 一些子系統(tǒng)在補(bǔ)丁追溯方面做得很好，而其他子系統(tǒng)則較差。對(duì)于穩(wěn)定內(nèi)核的使用，一般Red Hat只是編譯了一下并用它來(lái)和RHEL內(nèi)核做對(duì)比測(cè)試，以確定這些錯(cuò)誤是來(lái)自上游還是在RHEL中引入的。

企業(yè)例子之二(SUSE和Ubuntu)

再看看SUSE，他們確實(shí)在構(gòu)建穩(wěn)定內(nèi)核，但他們僅僅是為了挑選(cherry-pick)補(bǔ)丁。他們有考慮將穩(wěn)定的內(nèi)核測(cè)試添加到SUSE的測(cè)試網(wǎng)格(testing grid)中，但大家還不清楚它會(huì)對(duì)公司帶來(lái)什么樣的價(jià)值。Ubuntu面對(duì)的情況也是類(lèi)似的：他們除了建立穩(wěn)定的內(nèi)核以外，并沒(méi)有對(duì)它們進(jìn)行正式的測(cè)試。

企業(yè)例子之三(Linaro)

Linaro目前正在為谷歌開(kāi)發(fā)一個(gè)使用內(nèi)核自檢(kernel self-tests，縮寫(xiě)kselftest)和Linux測(cè)試項(xiàng)目(Linux Test Project，縮寫(xiě)LTP)來(lái)測(cè)試穩(wěn)定的內(nèi)核項(xiàng)目，這些測(cè)試會(huì)針對(duì)每個(gè)穩(wěn)定的發(fā)布版本來(lái)進(jìn)行。自檢測(cè)試的確能發(fā)現(xiàn)bug，但編寫(xiě)這些自檢測(cè)試的人可能并不是引入大多數(shù)錯(cuò)誤的人。所以自檢測(cè)試還只是一個(gè)開(kāi)始，顯然Linaro還需要增加更多的測(cè)試。

所以綜合來(lái)看，版本發(fā)布者一般都只是關(guān)心，合并到穩(wěn)定版本里的修復(fù)(fix)是否是正確的，但是他們只是從穩(wěn)定版本中摘出修復(fù)(fix)然后放到自己的內(nèi)核中做測(cè)試，對(duì)穩(wěn)定內(nèi)核本身的測(cè)試是非常有限的。于是有人建議可以由Linux基金會(huì)與Canonical，SUSE，Red Hat等公司一起組建一個(gè)合作項(xiàng)目，大家一起貢獻(xiàn)一部分機(jī)器同時(shí)形成一套測(cè)試套件來(lái)進(jìn)行穩(wěn)定內(nèi)核的測(cè)試。

測(cè)試的不斷改善

例一：0天內(nèi)核測(cè)試服務(wù)(0-Day kernel test service)。這個(gè)服務(wù)也不僅僅是構(gòu)建和引導(dǎo)測(cè)試(build-and-boot tests)，還包括一些性能測(cè)試。 kernelci.org項(xiàng)目也正在對(duì)許多不同的硬件進(jìn)行構(gòu)建和引導(dǎo)測(cè)試(build-and-boot tests)，這些都是非常有價(jià)值的，但他們沒(méi)有做任何真正的功能性的測(cè)試。當(dāng)然事情肯定會(huì)變得越來(lái)越好，大家不都是說(shuō)“有比沒(méi)有好么”。

例二：LTP(Linux Test Project)。它可以測(cè)試很多東西，但也有很多地方它并不會(huì)去測(cè)試。它會(huì)被一些發(fā)行版使用，然后也肯定能在里面發(fā)現(xiàn)一些bug，但很明顯我們需要更多更好的測(cè)試套件。

例三：性能測(cè)試(benchmark)和模糊測(cè)試(fuzzing)。會(huì)上還討論了穩(wěn)定內(nèi)核的模糊測(cè)試。模糊測(cè)試上游內(nèi)核是一種***的選擇，因?yàn)樗袉?wèn)題的修補(bǔ)都在那里，但它仍然可以在發(fā)行版的內(nèi)核中發(fā)現(xiàn)問(wèn)題。目前syzkaller fuzzer已經(jīng)可以針對(duì)它發(fā)現(xiàn)的問(wèn)題自動(dòng)生成小的測(cè)試用例，大家也覺(jué)得這些應(yīng)該被加入自檢測(cè)試集。雖然有人提到一些BUG只在Kernel Address Sanitizer(縮寫(xiě)KASAN)下才會(huì)出現(xiàn)，但這些測(cè)試在那些沒(méi)有被配置KASAN的內(nèi)核上運(yùn)行的時(shí)候是可以簡(jiǎn)單地被跳過(guò)的。除了找BUG的測(cè)試之外，內(nèi)核還需要更多的性能測(cè)試來(lái)發(fā)現(xiàn)性能退化(performance regressions)，有人提到可以用Mel Gorman的MMTests作為“kbench”這一性能測(cè)試套件的基礎(chǔ)，只是這個(gè)套件對(duì)應(yīng)的文檔很少了，所以我們需要在內(nèi)核文檔目錄中建立一個(gè)測(cè)試套件目錄作為一個(gè)開(kāi)始，但任何復(fù)雜的性能測(cè)試顯然需要更加深入的文檔。

例四：基準(zhǔn)數(shù)字(single number)。有人提議說(shuō)，如果我們有一個(gè)性能測(cè)試然后給出一個(gè)基準(zhǔn)數(shù)字，而我們可以基于這個(gè)數(shù)字來(lái)判斷性能是否有退化就***了(比如BogoMips背后的想法)，當(dāng)然有另外一些人會(huì)質(zhì)疑是否真的存在這樣的測(cè)試系統(tǒng)。

例五：自我測(cè)試(self-tests)。越來(lái)越多的自我測(cè)試，正在被添加到內(nèi)核主線中，但是穩(wěn)定的內(nèi)核卻不會(huì)從中受益。有些人正在使用較老的內(nèi)核進(jìn)行***的自我檢測(cè)，于是有人提議也許自我測(cè)試本身應(yīng)該被移植到穩(wěn)定的內(nèi)核樹(shù)中。

例六：神經(jīng)網(wǎng)絡(luò)訓(xùn)練。隨著B(niǎo)oF的結(jié)束，Levin要求發(fā)行版的維護(hù)者將他們正在使用的補(bǔ)丁推向穩(wěn)定的分支中去。一般發(fā)行版中的問(wèn)題在穩(wěn)定內(nèi)核中也一定存在。他最近一直在努力訓(xùn)練一個(gè)神經(jīng)網(wǎng)絡(luò)來(lái)識(shí)別適用于穩(wěn)定內(nèi)核的補(bǔ)丁，這引起了一些笑聲，但他說(shuō)結(jié)果是“出人意料的好”。

內(nèi)核測(cè)試的一些其他聲音

Greg Kroah-Hartman是穩(wěn)定內(nèi)核的維護(hù)者，他沒(méi)有參加BoF但是其實(shí)對(duì)BoF的討論內(nèi)容也有興趣。于是第二天當(dāng)Levin在一個(gè)小型會(huì)議中概括總結(jié)BoF的討論結(jié)果的時(shí)候，Greg給出了他的一些意見(jiàn)。

首先正如Levin所說(shuō)，在BoF中大家提出了很多的觀點(diǎn)，但是并沒(méi)有什么相應(yīng)的解決措施。有人建議應(yīng)該向kernelci.org項(xiàng)目提供更多的硬件，Kroah-Hartman同時(shí)希望能看到更多的功能測(cè)試。另外還有一些人提議應(yīng)該讓Linaro和kernelci.org一起努力合作這樣更好。

關(guān)于移植自我檢測(cè)(self-tests)，Kroah-Hartman并不反對(duì)這個(gè)想法，只要它們能在出問(wèn)題的內(nèi)核上運(yùn)行就可以。他也同意如果發(fā)行版能將它們的修補(bǔ)補(bǔ)丁打在穩(wěn)定的分支(tree)上，那將是一件很好的事情，而且他提到Fedora和Debian已經(jīng)在該領(lǐng)域做得很好。另一位與會(huì)者表示，發(fā)行版經(jīng)常會(huì)盡快為用戶快速解決問(wèn)題，然后才會(huì)做好上游內(nèi)核的工作。 Kroah-Hartman表示，如果有BUG在上游內(nèi)核中沒(méi)有被修復(fù)的話，他也不會(huì)在穩(wěn)定內(nèi)核中修復(fù)，這樣一方面上游內(nèi)核和穩(wěn)定內(nèi)核做到了“bug兼容”，另一方面也給了那些廠商一些壓力來(lái)修復(fù)它。

結(jié)語(yǔ)

我們需要進(jìn)行更多的內(nèi)核測(cè)試，這是毋庸置疑的，但是它究竟應(yīng)該采用什么樣的形式以及由誰(shuí)來(lái)做仍然不清晰。如果幸運(yùn)的話，在不久的將來(lái)這塊會(huì)有一些進(jìn)展，同時(shí)也意味著我們有可能會(huì)更早地發(fā)現(xiàn)BUG。當(dāng)然，***是不可能的，但是我們大家都希望能夠減少內(nèi)核里的錯(cuò)誤，對(duì)么?另外一點(diǎn)，大家對(duì)于上游內(nèi)核(upstream)的熱情是遠(yuǎn)遠(yuǎn)高于穩(wěn)定內(nèi)核(stable)的，所以對(duì)于穩(wěn)定內(nèi)核的測(cè)試肯定仍然會(huì)比較少，所以穩(wěn)定內(nèi)核的“穩(wěn)定性”是大打折扣的。