Linux驅(qū)動(dòng)中斷上下文中會(huì)發(fā)生什么結(jié)果實(shí)驗(yàn)測試

一、前言

每一個(gè)Linux驅(qū)動(dòng)工程師都知道這樣一個(gè)準(zhǔn)則：在中斷上下文中不能睡眠。但是為什么interrupt context中不能調(diào)用導(dǎo)致睡眠的kernel API呢？如果驅(qū)動(dòng)這么做會(huì)導(dǎo)致什么樣的后果呢？這就是本文探討的主題。為了理解這個(gè)主題，我們?cè)O(shè)計(jì)了一些非常簡單的驅(qū)動(dòng)程序和用戶空間的程序，實(shí)際做實(shí)驗(yàn)觀察實(shí)驗(yàn)效果，最后給出了結(jié)果和分析。

BTW，本文的實(shí)驗(yàn)在X86 64bit ＋ 標(biāo)準(zhǔn)4.4內(nèi)核上完成。

二、測試程序

1、cst驅(qū)動(dòng)模塊

我們首先準(zhǔn)備一個(gè)能夠在中斷上下文中睡眠的驅(qū)動(dòng)程序，在這里我稱之Context schedule test module（后文簡稱cst模塊）。這個(gè)驅(qū)動(dòng)程序類似潛伏在內(nèi)核中的“搗蛋鬼”，每隔1秒隨機(jī)命中一個(gè)進(jìn)程，然后引發(fā)調(diào)度。首先準(zhǔn)備一個(gè)Makefile，代碼如下：

按理說代碼中的xxxx應(yīng)該是我的名字，如果你愿意在你的環(huán)境中測試，可以修改成你的名字，當(dāng)然，最重要的是需要某個(gè)版本的內(nèi)核代碼。在內(nèi)核升級(jí)文檔中，我已經(jīng)編譯了/home/xxxx/work/linux-4.4.6目錄下的內(nèi)核，并把我的計(jì)算機(jī)升級(jí)到4.4.6的內(nèi)核上，如果你愿意可以按照那份文檔進(jìn)行升級(jí)，否則可能會(huì)有一些版本問題需要處理。除了Makefile之外，還需要一個(gè)Kbuild文件：

obj-m := cst.o

當(dāng)然，最重要的是cst模塊的源代碼：

代碼非常的簡單，無需多說，直接make就可以編譯得到cst.ko的內(nèi)核模塊了。

2、用戶空間測試程序

為了更方便的測試，我們需要準(zhǔn)備一個(gè)“受害者”，代碼如下：

這段代碼也很簡單：不斷的產(chǎn)生一個(gè)隨機(jī)數(shù)，并運(yùn)算其平方根，在使得的時(shí)候，向用戶輸出一些字符，表明自己的狀態(tài)。當(dāng)程序執(zhí)行起來的時(shí)候，大部分時(shí)間在用戶態(tài)（運(yùn)算），偶爾進(jìn)入內(nèi)核態(tài)（printf）。這個(gè)進(jìn)程并不知道在內(nèi)核態(tài)有一個(gè)cst的模塊，每隔一秒就發(fā)射一只休眠之箭，可能命中用戶態(tài)，也可能命中內(nèi)核態(tài)，看運(yùn)氣吧，但是無論怎樣，該進(jìn)程被射中之后都會(huì)進(jìn)入睡眠。

三、執(zhí)行測試并觀察結(jié)果

1、先把用戶空間的測試程序跑起來

要想測試導(dǎo)彈（呵呵～～我們的cst模塊就是一個(gè)搗蛋） 的性能，必須要有靶機(jī)或者靶艦。當(dāng)然也可以不用“靶機(jī)”程序，只不過搗蛋鬼cst總是命中swapper進(jìn)程，有點(diǎn)無趣，因此這里需要把我們用戶空間的那個(gè)測試程序跑起來，讓CPU先活躍起來。

需要注意的是，在多核cpu上，我們需要多跑幾個(gè)“靶機(jī)”進(jìn)程才能讓系統(tǒng)不會(huì)always進(jìn)入idle狀態(tài)。例如我的T450是4核cpu，因此我需要運(yùn)行4個(gè)靶機(jī)程序才能讓系統(tǒng)中的4個(gè)cpu core都燥起來?？梢酝ㄟ^下面的命令確認(rèn)：

ps –eo comm,psr | grep cst

BTW，靶機(jī)程序是cst_test。通過上面的命令，可以看到系統(tǒng)中運(yùn)行了四個(gè)cst_test進(jìn)程，分別在4個(gè)cpu上。

2、插入內(nèi)核模塊

靶機(jī)已經(jīng)就緒，是時(shí)候發(fā)射搗蛋了，命令如下：

sudo insmod ./cst.ko

一旦插入了cst內(nèi)核模塊，搗蛋鬼就開始運(yùn)作了，每隔1秒鐘發(fā)射一次，總有一個(gè)倒霉蛋被命中，被調(diào)度。當(dāng)然，在我們的測試中，一般總是cst_test這個(gè)進(jìn)程被命中。

3、觀察結(jié)果

一切準(zhǔn)備就緒，是時(shí)候搬個(gè)小板凳坐下來看好戲了。當(dāng)然，我們需要一個(gè)觀察的工具，輸入如下命令：

sudo tail –f /var/log/messages

在上面的cst模塊中，輸出并沒有直接到控制臺(tái)，因此我們需要通過內(nèi)核日志來看看cst的運(yùn)行情況。

四、結(jié)果和分析

1、結(jié)果

很奇怪，一切都是正常的，系統(tǒng)沒有死，cst模塊也運(yùn)行正常，cst_test進(jìn)程也始終保持alive狀態(tài)，不斷的運(yùn)行在無聊的平方根、打印著無聊的字符串。唯一異常的是日志，每隔1秒鐘就會(huì)dump stack一次。

2、分析

當(dāng)cst模塊命中cst_test進(jìn)程，無論是userspace還是kernel space，都會(huì)在內(nèi)核棧上保存中斷發(fā)生那一點(diǎn)的上下文，唯一不同是如果發(fā)生在userspace，那么發(fā)生中斷那一刻，內(nèi)核棧是空的，而如果在kernel space，內(nèi)核棧上已經(jīng)有了cst_test通過系統(tǒng)調(diào)用進(jìn)入內(nèi)核的現(xiàn)場以及該系統(tǒng)調(diào)用各個(gè)函數(shù)的stack frame，當(dāng)中斷發(fā)生的時(shí)候，在當(dāng)前內(nèi)核棧的棧頂上繼續(xù)壓入了中斷現(xiàn)場，之后就是中斷處理的各個(gè)函數(shù)的stack frame，最后是cst_timer_handler的stack frame，由于調(diào)用了schedule函數(shù)，cst_test進(jìn)程的現(xiàn)場被繼續(xù)壓入內(nèi)核棧，調(diào)度器決定下一個(gè)調(diào)度的進(jìn)程。

cst_test進(jìn)程雖然被調(diào)度了，但是仍然在runqueue中，調(diào)度器一定會(huì)在適當(dāng)?shù)臅r(shí)機(jī)調(diào)度cst_test進(jìn)程重新進(jìn)入執(zhí)行態(tài)，這時(shí)候恢復(fù)其執(zhí)行就OK了，cpu執(zhí)行cst_timer_handler函數(shù)schedule之后的代碼，繼續(xù)未完的中斷上下文的執(zhí)行，然后從內(nèi)核棧恢復(fù)中斷現(xiàn)場，一切又按照原路返回了。

當(dāng)然，這里的測試看起來一切OK，但這并不是說可以自由的在中斷上下文中調(diào)用導(dǎo)致睡眠的內(nèi)核API，因?yàn)槲覀冞@里給出了一個(gè)簡單的例子，實(shí)際上也有可能導(dǎo)致系統(tǒng)死鎖。例如在內(nèi)核態(tài)持有鎖的時(shí)候被中斷，然后發(fā)生調(diào)度。有興趣的同學(xué)可以自己修改上面的代碼實(shí)驗(yàn)這種情況。

3、why

最后還是回到這個(gè)具體的技術(shù)問題：為什么interrupt context中不能調(diào)用導(dǎo)致睡眠的kernel API？

我的看法是這樣的：調(diào)度器是每一個(gè)OS的必備組件，在編碼階段之前，我們往往要制定下我們的設(shè)計(jì)概念。對(duì)于Linux 調(diào)度器，它的目標(biāo)就是調(diào)度一個(gè)線程，一個(gè)線程就是調(diào)度實(shí)體（暫不考慮group sched）。中斷上下文是不是調(diào)度實(shí)體呢？當(dāng)然不是，它沒有專屬的task struct，內(nèi)核無從調(diào)度。這是調(diào)度器設(shè)計(jì)者的決定，這樣的決定讓調(diào)度器設(shè)計(jì)起來簡潔而美麗。

基于上面的設(shè)計(jì)概念，中斷上下文（hard irq和softirq context）并不參與調(diào)度（暫不考慮中斷線程化），它們是異步事件的處理機(jī)制，目標(biāo)就是盡快完成處理，返回現(xiàn)場。因此，所有中斷上下文的優(yōu)先級(jí)都是高于進(jìn)程上下文的，也就是說，對(duì)于用戶進(jìn)程（無論內(nèi)核態(tài)還是用戶態(tài)）或者內(nèi)核線程，除非disable了CPU的本地中斷，否則一旦中斷發(fā)生，它們是沒有任何能力阻擋中斷上下文搶占當(dāng)前進(jìn)程上下文的執(zhí)行的。

因此，Linux kernel的設(shè)計(jì)者制定了規(guī)則：

1、中斷上下文不是調(diào)度實(shí)體

2、中斷上下文的優(yōu)先級(jí)高于進(jìn)程上下文

而在中斷上下文中調(diào)度毫無疑問會(huì)打破規(guī)則，因此不能在硬中斷、軟中斷環(huán)境中調(diào)用阻塞函數(shù)。不過，在linux調(diào)度器的具體實(shí)現(xiàn)的時(shí)候，檢測到了在中斷上下文中調(diào)度schedule函數(shù)也并沒有強(qiáng)制linux進(jìn)入panic，可能是linux的開發(fā)者認(rèn)為一個(gè)好的內(nèi)核調(diào)度器無論如何也盡自己最大的努力讓系統(tǒng)運(yùn)行下去吧。但是，在廠商自己提供的內(nèi)核中，往往修改調(diào)度器行為，在中斷上下文中檢測到調(diào)度就直接panic了，對(duì)于內(nèi)核開發(fā)者而言，這樣更好，可以盡早的發(fā)現(xiàn)問題。