本文經(jīng)AI新媒體量子位（公眾號ID:QbitAI）授權(quán)轉(zhuǎn)載，轉(zhuǎn)載請聯(lián)系出處。

還在使用89年版C語言的Linux內(nèi)核，現(xiàn)在終于要做出改變了。

今天，Linux開源社區(qū)宣布，未來會把內(nèi)核C語言版本升級到C11，預(yù)計5.18版之后生效，也就是今年5月。

這個決定很突然，從發(fā)起問題到官方聲明，不過才一個星期，要知道說服固執(zhí)的Linux之父 Linus Torvalds可不是件容易的事。

事情的原因，說起來還有那么一點偶然的因素。

一個bug的連鎖反應(yīng)

問題的起源是來自上周的一次Linux社區(qū)討論。

一位名叫Jakob Koschel的博士生，在研究阻止與內(nèi)核鏈表primitive相關(guān)的預(yù)測執(zhí)行漏洞時，發(fā)現(xiàn)了這樣一個問題。

Linux內(nèi)核廣泛使用由struct list_head定義的雙向鏈表：

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

這種結(jié)構(gòu)通常嵌入到其他結(jié)構(gòu)中。通過這種方式，可以使用任何相關(guān)的結(jié)構(gòu)類型制作鏈表。

除此之外，內(nèi)核還提供大量可用于遍歷和操作鏈表的函數(shù)和宏。list_for_each_entry()就是其中之一，這是偽裝成一種控制結(jié)構(gòu)的宏。

問題就出在這個宏上。

假設(shè)內(nèi)核包含如下結(jié)構(gòu)：

struct foo {
  int fooness;
  struct list_head list;
  };

list中的元素可用于創(chuàng)建foo結(jié)構(gòu)的雙向鏈表。

假設(shè)有一個叫做 foo_list的結(jié)構(gòu)聲明作為此類鏈表的頭，使用以下代碼可以遍歷此鏈表：

struct foo *iterator;


    list_for_each_entry(iterator, &foo_list, list) {
        do_something_with(iterator);
    }
    /* Should not use iterator here */

list參數(shù)告訴宏在foo結(jié)構(gòu)中l(wèi)ist_head結(jié)構(gòu)的名稱。這個循環(huán)將為列表中的每個元素執(zhí)行一次， 迭代器指向該元素。

由此導(dǎo)致了USB子系統(tǒng)中的一個bug：傳遞給該宏的迭代器在退出宏后還能被使用。

這是一件危險的事情，所以Koschel提交了一個修復(fù)補丁，在循環(huán)后停止使用迭代器搞定了bug。

說服Linus

但是Linus Torvalds本人并不太喜歡這個補丁，也沒有看到它與預(yù)測執(zhí)行漏洞的關(guān)系。在Koschel詳細(xì)解釋后，Linus承認(rèn)這只是一個普通的bug。

然而事情并沒有那么簡單，Linus不久后意識到了真正的根源：

傳遞給鏈表遍歷宏的迭代器，必須在循環(huán)本身之外的范圍內(nèi)聲明。

這種非預(yù)測性bug發(fā)生的原因是，C89中沒有“在循環(huán)中聲明變量”。

像list_for_each_entry()這樣的宏，從根本上總是將最后一個HEAD入口泄漏到循環(huán)之外，僅僅是因為我們不能在循環(huán)本身中聲明迭代器變量。

如果可以編寫一個可以聲明自己的迭代器列表遍歷宏，那么迭代器在循環(huán)之外將不可見，并且不會出現(xiàn)此類問題。

但是，由于內(nèi)核停留在C89標(biāo)準(zhǔn)上，因此無法在循環(huán)中聲明變量。

Linus決定，那咱們還是升級吧，也許是時候轉(zhuǎn)向C99標(biāo)準(zhǔn)了。

雖然它也有20多年的歷史，但至少比C89新，可以在循環(huán)中聲明變量。

既然C89如此陳舊，這么多年還沒做出改變呢？Linus說，那是因為我們在一些古老的gcc編譯器版本中遇到了一些奇怪的問題，不能隨便升級。

但是，現(xiàn)在Linux內(nèi)核已將gcc的最低要求提升至5.1版，因此過去那些奇怪的bug應(yīng)該不會有了。

而另一位核心開發(fā)者Arnd Bergmann認(rèn)為，咱們完全可以升級到C11甚至更高版本。但如果升級到C17或C2x，會破壞對gcc-5/6/7的支持，因此升級到C11更容易實現(xiàn)。

最終，Torvalds贊成這個想法：“好的，請?zhí)嵝盐?，讓我們?.18合并窗口的早期嘗試一下?！?/span>

接下來遷移到C11可能會導(dǎo)致一些意想不到的bug，但如果一切順利，下一個Linus內(nèi)核版本將正式轉(zhuǎn)向C11。