一、前言

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

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

二、測試程序

1、cst驅(qū)動模塊

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

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

obj-m := cst.o

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

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

2、用戶空間測試程序

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

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

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

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

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

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

ps –eo comm,psr | grep cst

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

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

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

sudo insmod ./cst.ko

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

3、觀察結(jié)果

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

sudo tail –f /var/log/messages

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

四、結(jié)果和分析

1、結(jié)果

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

2、分析

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

cst_test進程雖然被調(diào)度了，但是仍然在runqueue中，調(diào)度器一定會在適當(dāng)?shù)臅r機調(diào)度cst_test進程重新進入執(zhí)行態(tài)，這時候恢復(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，因為我們這里給出了一個簡單的例子，實際上也有可能導(dǎo)致系統(tǒng)死鎖。例如在內(nèi)核態(tài)持有鎖的時候被中斷，然后發(fā)生調(diào)度。有興趣的同學(xué)可以自己修改上面的代碼實驗這種情況。

3、why

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

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

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

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

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

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

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