前言

什么是Oops？從語言學的角度說，Oops應該是一個擬聲詞。當出了點小事故，或者做了比較尷尬的事之后，你可以說"Oops"，翻譯成中國話就叫做“哎呦”?！鞍ミ希瑢Σ黄?，對不起，我真不是故意打碎您的杯子的”。看，Oops就是這個意思。

(資料圖片)

在Linux內(nèi)核開發(fā)中的Oops是什么呢？其實，它和上面的解釋也沒什么本質(zhì)的差別，只不過說話的主角變成了Linux。當某些比較致命的問題出現(xiàn)時，我們的Linux內(nèi)核也會抱歉的對我們說：“哎呦(Oops)，對不起，我把事情搞砸了”。Linux內(nèi)核在發(fā)生kernel panic時會打印出Oops信息，把目前的寄存器狀態(tài)、堆棧內(nèi)容、以及完整的Call trace都show給我們看，這樣就可以幫助我們定位錯誤。

1. Oops的產(chǎn)生

挑選一位隨機幸運內(nèi)核，insmod oops.ko產(chǎn)生如下標準打印，產(chǎn)生了一段如下圖打?。?Oops 信息包含以下幾部分內(nèi)容：

一段文本描述信息。 比如類似“Unable to handle kernel NULL pointer dereference at virtual address 00000000”的信息,它說明了發(fā)生的是哪類錯誤Oops 信息的序號 比如是第 1 次、第 2 次等。這些信息與下面類似,中括號內(nèi)的數(shù)據(jù)表示序號。 Internal error: Oops: 817 [#1] PREEMPT SMP ARM內(nèi)核中加載的模塊名稱(也可能沒有)，以下面字樣開頭 Modules linked in:xxx發(fā)生錯誤的 CPU 的序號,對于單處理器的系統(tǒng),序號為 0 CPU: 1 PID: 1412 Comm: insmod Tainted: P O 4.9.37 #1 下圖是關(guān)于Tainted(污染)后面字段具體含義(可以注意到，第3部分加載的模塊后面有些模塊帶有(PO)等字樣，實際上就是和這里是相同的含義)，源碼路徑: \kernel\panic.c

/** *  print_tainted - return a string to represent the kernel taint state. * *  "P" - Proprietary module has been loaded.（沒有模塊MODULE_LICENSE或者帶有insmod認為是與GPL不相容的的MODULE_LICENSE的模塊被認定是專有的） *  "F" - Module has been forcibly loaded.（通過“insmod -f”被強制裝載的模塊） *  "S" - SMP with CPUs not designed for SMP.（oops發(fā)生在SMP內(nèi)核中，運行于沒有證明安全運行多處理器的硬件。 當前這種情況僅限于幾種不支持SMP的處理器） *  "R" - User forced a module unload.（rmmod –f強制卸載） *  "M" - System experienced a machine check exception.（機器檢查異常） *  "B" - System has hit bad_page.（頁釋放函數(shù)發(fā)現(xiàn)了一個錯誤的頁引用或者一些非預期的頁標志） *  "U" - Userspace-defined naughtiness. *  "D" - Kernel has oopsed before.（內(nèi)核以前已經(jīng)OOPS過了） *  "A" - ACPI table overridden. *  "W" - Taint on warning. *  "C" - modules from drivers/staging are loaded. *  "I" - Working around severe firmware bug. *  "O" - Out-of-tree module has been loaded.（樹外模塊加載） *  "E" - Unsigned module has been loaded.（未簽名模塊加載） *  "L" - A soft lockup has previously occurred.（發(fā)生過軟鎖定） *  "K" - Kernel has been live patched. * *  The string is overwritten by the next call to print_tainted().*/

發(fā)生錯誤時 CPU 的各個寄存器值

當前進程的名字及進程 ID Process insmod (pid: 1412, stack limit = 0x9eb8e210) 這并不是說發(fā)生錯誤的是這個進程,而是表示發(fā)生錯誤時,當前進程是它。錯誤可能發(fā)生在內(nèi)核代碼、驅(qū)動程序,也可能就是這個進程的錯誤

棧信息

?；厮菪畔?可以從中看出函數(shù)調(diào)用關(guān)系

出錯指令附近的指令的機器碼(出錯指令在小括號里)，也有可能沒有 關(guān)于錯誤碼，如下為armv7架構(gòu)定義的FSR(錯誤狀態(tài)寄存器，分為DFSR和IFSR，根據(jù)不同處理器使用不同的FSR)的錯誤代碼，實際上源碼中，oops的錯誤碼就是通過匯編獲取的寄存器值，如下為手冊中IFSR獲取錯誤碼的方法(DFSR同樣) 如下為DFSR結(jié)構(gòu)(IFSR關(guān)于FS碼是相同的) 對于上面0x817的錯誤碼解釋為：寫入內(nèi)存時報錯，錯誤原因是：Translation fault 也就是頁表轉(zhuǎn)換出現(xiàn)問題

從上可以大致知道Oops 可以看成是內(nèi)核級的Segmentation Fault。應用程序如果進行了非法內(nèi)存訪問或執(zhí)行了非法指令，會得到Segfault信號，一般的行為是coredump，應用程序也可以自己截獲 Segfault信號，自行處理。如果內(nèi)核自己犯了這樣的錯誤，則會打出Oops信息，也就是說Oops一般是由于內(nèi)存原因?qū)е碌摹?/p>

2.源碼分析

2.1 溯源過程C部分

直接通過打印找到產(chǎn)生的對應代碼，oops的打印為__die函數(shù)(\arch\arm\kernel\traps.c)。 第265行打印就是oops信息，后邊三個字符串來自三個編譯開關(guān)，分別表示允許搶占，支持對稱多處理器，采用ARM指令。 第269行忽略，備注也寫的陷阱和錯誤數(shù)在ARM上幾乎沒有意義 第273行，打印加載的模組信息 第274行，打印寄存器信息（CPU號，任務名，污染原因，PC,LR(鏈接寄存器，保存函數(shù)返回的地址),SP(棧指針),IP,FP(棧頂指針),R10-R0等寄存器值，CPU的Flags (Flags后邊大寫字母表示相應的位為1，小寫表示為0)【指NZCV這幾個狀態(tài)寄存器】） 第275行，打印了當前出錯的進程名，pid值，和堆棧限制，在ARM平臺棧的增長方向是從高地址向低地址，sp指針是當前的棧頂，stack limit打印的是棧的限制，表示最小地址是多少，如果SP比這個值小，那么表示棧溢出了。 第279行之后打印堆棧和函數(shù)的調(diào)用回溯。 如下為pt_reg的定義 進一步溯源，深入探究oops源碼，調(diào)用__die的函數(shù)為die(\arch\arm\kernel\traps.c)： 第344行：調(diào)用oops_begin，在這個地方關(guān)閉本CPU中斷，獲取CPUID, 對oops上鎖.如果同一個CPU已經(jīng)在處理die了，那么就是嵌套die，不需要再獲取鎖了 第347行獲取cpu是不是處于用戶模式，如果不是用戶模式并且report_bug的返回值如果不等于BUG_TRAP_TYPE_NONE打印會變?yōu)椤監(jiān)ops - BUG”，如果是這種情況，就比較嚴重，一般會打印如下 第355行：die的最后是調(diào)用oops_end，這里邊的操作很多是和oops_begin相對應的，然后調(diào)用oops_exit，該函數(shù)會打印trace結(jié)束標志，調(diào)用kmsg_dump(KMSG_DUMP_OOPS)。但是如果oops產(chǎn)生在中斷過程中，oops_end函數(shù)會直接產(chǎn)生panic或者如果配置宏CONFIG_PANIC_ON_OOPS_VALUE的值為1(panic_on_oops)，則也會直接panic 通常情況由于空指針或者錯誤的虛擬地址導致的oops，函數(shù)為：__do_kernel_fault。源碼位于\arch\arm\mm\fault.c 第138行：嘗試進行異常修復，這里有一套很復雜的內(nèi)存異?；貜吞幚?，不深入，失敗后會繼續(xù)向下執(zhí)行 第152行：執(zhí)行完前面的die操作后，直接干掉出問題的進程 繼續(xù)溯源，可以找到在\arch\arm\mm\fault.c中發(fā)現(xiàn)兩個函數(shù)都有調(diào)用__do_kernel_fault。分別是do_bad_area和do_page_fault，這里先不具體分析其源碼，繼續(xù)溯源

調(diào)用do_bad_area函數(shù)的有如下函數(shù)：do_alignment，do_translation_fault，do_sect_fault 調(diào)用do_page_fault函數(shù)的有：do_translation_fault 而最終匯總成如下該數(shù)組 最終由函數(shù)do_DataAbort調(diào)用

2.2溯源過程匯編部分

以下部分為匯編過程，并且涉及到部分內(nèi)存申請流程。 當內(nèi)核申請內(nèi)存時，虛擬內(nèi)存映射到實際物理內(nèi)存，系統(tǒng)自動觸發(fā)缺頁中斷，缺頁中斷機制根據(jù)所訪問頁面的狀態(tài)來分配物理頁面并建立映射關(guān)系。觸發(fā)缺頁中斷的情況有兩種 , 第一，程序訪問了非法地址(我們主要分析的)；第二，訪問的地址是合法的，但是該地址還未分配物理頁框。

當程序訪問的虛擬頁面沒有進行過物理頁面的映射時，會通過發(fā)生缺頁中斷來分配和映射物理頁面。發(fā)生缺頁中斷時，處理器會跳轉(zhuǎn)到異常向量表 Data abort 向量中開始執(zhí)行缺頁中斷的匯編階段，這個階段與處理器架構(gòu)緊密聯(lián)系，例如對于ARMv7-A架構(gòu)，匯編處理流程為：__vectors_start -> vector_dabt -> __dabt_usr/__dabt_svc -> dabt_helper -> v7_early_abort 如下為中斷向量表，源碼位于：arch\arm\kernel\entry-armv.S

以svc為例，會調(diào)用dabt_helper 最后dabt_helper會bl到CPU_DABORT_HANDLER這個函數(shù)中，根據(jù)使用的架構(gòu)不同，該函數(shù)使用的可能會不相同 如下使用的v7架構(gòu)，使用函數(shù)為v7_early_abort v7_early_abort源碼位于：\arch\arm\mm\abort-ev7.S 這個函數(shù)實際上就是實現(xiàn)了從arm中獲取FSR(錯誤狀態(tài)寄存器)和FAR(錯誤地址寄存器，也就是要映射的地址)，r0=地址，ri=錯誤碼，r2=pt_regs(在對應的__dabt_svc中已經(jīng)獲取)

2.3 do_DataAbort的函數(shù)注冊

從2.1和2.2分別對C部分和匯編部分進行簡單的分析，下面來看一下do_DataAbort是如何識別不同的頁面分配的 如下函數(shù)為對fsr_info數(shù)組的注冊函數(shù)，因為do_DataAbort實際上就是根據(jù)fsr_info這個數(shù)組進行函數(shù)調(diào)用的 全局搜索hook_fault_code可以發(fā)現(xiàn)如下：實際上也就是對fsr_info數(shù)組補齊了段錯誤的函數(shù)回調(diào) 也就是說，接下來只要對著fsr_info數(shù)組這個數(shù)組進行分析，就能知道oops的全部產(chǎn)生原因了

2.4 總流程圖

3.oops產(chǎn)生原因分析

如下表，為匯總的frs_info，包括對齊，頁表轉(zhuǎn)換，頁，段權(quán)限 我們繼續(xù)對源碼進行分析。如下圖為do_DataAbort函數(shù)中對fsr寄存器讀取數(shù)據(jù)的處理。也就是對fsr寄存器取fs，因為fs分布為fs[3:0]位于bit3:0，fs[4]位于bit10，所以處理后對fsr_info進行直接查表即可 第547行如上分析 第550行執(zhí)行表中對應函數(shù)，只有do_bad會返回1，其余函數(shù)皆返回0. 第561行，執(zhí)行由于do_bad對應的fsr導致的錯誤，arm_notify_die中判斷當前CPU是否處于用戶態(tài)，如果不是則執(zhí)行die

3.1 do_translation_fault

static int __kprobesdo_translation_fault(unsigned long addr, unsigned int fsr,             struct pt_regs *regs){/* …… */#define TASK_SIZE       (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))/* 如果是用戶空間的地址，用do_page_fault處理 */    if (addr < TASK_SIZE)         return do_page_fault(addr, fsr, regs);/* 至此的地址都是內(nèi)核空間，如果regs顯式為用戶空間。說明兩者沖突，進入bad_area */    if (user_mode(regs))          goto bad_area;    /* 中間略過一部分代碼 */    return 0;bad_area:    do_bad_area(addr, fsr, regs);    return 0;}

如下圖為do_bad_area源碼 第195判斷是否處于用戶模式，如果不是就Oops

3.2 do_page_fault

直接看下圖流程即可，不進行具體分析，總之在處于非用戶模式下缺頁且處理出現(xiàn)錯誤，會執(zhí)行__do_kernel_fault。題外：do_page_fault完成了真正的物理頁面分配工作，另外棧擴展、mmap的支持等也都在這里。對于物理頁面的分配，會調(diào)用到do_anonymous_page->。。。-> __rmqueue，__rmqueue中實現(xiàn)了物理頁面分配的伙伴算法

3.3 do_sect_fault

源碼如下，一旦出錯，直接do_bad_area

3.4 bad_mode

bad_mode(中斷異常)也可以導致die并且最終直接panic，源碼如下 引用流程：xx中斷異常 -> xx_invalid -> common_invalid -> bad_mode

3.5總結(jié)

4. Oops的解決思路

1.先看是否由BUG/BUG_ON引起，如果是BUG引起的，則直接看產(chǎn)生條件，這種具體情況具體分析 2.如果不是，則可以根據(jù)Oops現(xiàn)場打印進一步分析。我們繼續(xù)看在第一章中產(chǎn)生的Oops信息。如下圖。首先直接看到了錯誤原因，空指針引起的，然后看到錯誤碼0x817：即寫內(nèi)存時，缺頁，映射失敗。接下來直接看PC指針就行了 3.PC is at myoops_test_init +0xc/0x14 確定了出問題的函數(shù)位置，然后看一下出錯進程是insmod 也就是說就是在insmod oops.ko驅(qū)動時后出的問題。接下來需要對該進程增加調(diào)試信息，以供我們能夠找到出錯位置 4.增加 –g編譯選項，見下圖。如果file帶有stripped，說明makefile或者腳本中存在選項，將其暫時屏蔽即可。 5.對于內(nèi)核增加調(diào)試信息，直接搜索debug_info，將其打開即可 6.使用對應工具鏈的gbd定位問題源碼所在位置 查看代碼(默認顯示10行) l/list 例：l *(函數(shù)名+偏移) 然后根據(jù)定位到的對應源碼上下文繼續(xù)查找問題即可 7.使用addr2line定位內(nèi)核中問題源碼。如下圖為之前出現(xiàn)問題的一串oops打印?？梢园l(fā)現(xiàn)問題出現(xiàn)在dwc2_queue_transaction。我們直接找到內(nèi)核對應的符號表，找到該函數(shù)對應內(nèi)核的所在位置 確定其偏移為 0x8054ced8+0xf8=0x8054CFD0 使用命令 xxx(工具鏈)-addr2line -C -f -e vmlinux 8054CFD0，確定到了問題所在行數(shù)2805 附addr2line參數(shù)說明： (1).-a:在函數(shù)名、文件名和行號信息之前，以十六進制形式顯示地址。 (2).-b:指定目標文件的格式為bfdname。 (3).-C:將低級別的符號名解碼為用戶級別的名字。 (4).-e:指定需要轉(zhuǎn)換地址的可執(zhí)行文件名，默認文件是a.out。 (5).-f:在顯示文件名、行號信息的同時顯示函數(shù)名。 (6).-s:僅顯示每個文件名(the base of each file name)去除目錄名。 (7).-i:如果需要轉(zhuǎn)換的地址是一個內(nèi)聯(lián)函數(shù)，則還將打印返回第一個非內(nèi)聯(lián)函數(shù)的信息。 (8).-j:讀取指定section的偏移而不是絕對地址。 (9).-p:使打印更加人性化：每個地址(location)的信息都打印在一行上。 (10).-r:啟用或禁用遞歸量限制。 (11).–help:打印幫助信息。 (12).–version:打印版本號。

進階：反匯編方案，適合高手 使用命令：arm-seev100-linux-gnueabihf-objdump -d oops.ko > test.s 然后直接生擼匯編，從PC可以看出出錯在0xc。此時r3=0，r2=1。Str即將r2中數(shù)據(jù)給到r3指向的內(nèi)存即0。而0這個內(nèi)存地址很明顯是非法的