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

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

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

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

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

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

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

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

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

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

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

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

企業(yè)是如何做的

我們再把話題切回到穩(wěn)定內(nèi)核。如果我們可以阻止所有可能的bug引入到內(nèi)核，那么主線內(nèi)核（mainline）無疑是完美的，我們也就不需要什么穩(wěn)定分支了（stable trees）。當(dāng)然現(xiàn)實是殘酷的，完美也是不可能的，所以我們?nèi)匀恍枰€(wěn)定分支，但是發(fā)行版真的會使用穩(wěn)定分支么？讓我們一個一個看過去。

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

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

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

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

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

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

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

測試的不斷改善

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

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

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

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

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

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

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

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

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

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

結(jié)語

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