內(nèi)核是Linux系統(tǒng)的“心臟”——一旦它出bug，小則功能異常，大則系統(tǒng)崩潰、死機(jī)。但內(nèi)核bug往往藏在百萬(wàn)行代碼中，想快速定位、修復(fù)絕非易事。

好在Linux內(nèi)核官方提供了一份詳細(xì)的《bug狩獵手冊(cè)》（kernel.org/doc/html/latest/admin-guide/bug-hunting.html），從識(shí)別日志信號(hào)到提交修復(fù)補(bǔ)丁，全程拆解實(shí)用方法。今天我們就基于這份權(quán)威文檔，梳理一套“內(nèi)核bug排查實(shí)操指南”，幫你高效解決內(nèi)核故障。

一、先看懂內(nèi)核的“求救信號(hào)”：棧跟蹤與Oops信息

當(dāng)內(nèi)核遇到bug時(shí)，不會(huì)“沉默”——它會(huì)輸出棧跟蹤（stack dump）日志，告訴你“哪里出了問(wèn)題”。這類(lèi)日志通常分兩種場(chǎng)景：

1.常見(jiàn)的“警告型”日志（WARNING）

比如文檔中給出的例子，內(nèi)核會(huì)明確標(biāo)出出錯(cuò)的CPU、進(jìn)程、代碼位置：

------------[cuthere ]------------WARNING: CPU: 1 PID: 28102 at kernel/module.c:1108 module_put+0x57/0x70Modules linkedin: dvb_usb_gp8psk(-) dvb_usb dvb_core nvidia_drm(PO) ...CPU: 1 PID: 28102 Comm: rmmod Tainted: P    WC O 4.8.4-build.1#1Hardware name: MSI MS-7309/MS-7309, BIOS V1.12 02/23/2009...Call Trace: # 函數(shù)調(diào)用棧，記錄bug觸發(fā)時(shí)的代碼執(zhí)行路徑[] ? dump_stack+0x44/0x64[] ? __warn+0xfa/0x120[] ? module_put+0x57/0x70 # 關(guān)鍵：出錯(cuò)函數(shù)及偏移...

2.嚴(yán)重的“崩潰型”日志（Oops/BUG）

如果bug導(dǎo)致內(nèi)核無(wú)法繼續(xù)運(yùn)行，會(huì)輸出帶“BUG”或“Oops”的日志，比如空指針引用：

BUG: unable to handle kernelNULLpointer dereference at  (null)IP: [] iret_exc+0x7d0/0xa59# IP=指令指針，指向出錯(cuò)代碼地址Oops:0002[#1] PREEMPT SMP...

3.日志中的“模塊標(biāo)記”要注意

日志里“Modules linked in”后的模塊名，會(huì)帶特殊標(biāo)記，暗示模塊狀態(tài)：

?(PO)：模塊處于“待處理”狀態(tài)（Pending）；

?(-)：模塊正在卸載；

?(+)：模塊正在加載；

?Tainted: P WC O：內(nèi)核被“污染”（比如加載了非開(kāi)源模塊，影響調(diào)試）。

二、別讓關(guān)鍵日志溜走：找到Oops信息的3種場(chǎng)景

想定位bug，首先得拿到完整的Oops日志——內(nèi)核會(huì)把日志存在不同地方，分場(chǎng)景獲?。?/span>

1.系統(tǒng)還能操作：從常規(guī)日志文件拿

內(nèi)核默認(rèn)通過(guò)klogd把日志傳給syslogd，存到這些位置：

?傳統(tǒng)系統(tǒng)：/var/log/messages（路徑由/etc/syslog.conf配置）；

?systemd系統(tǒng)：用journalctl命令查看（比如journalctl -k只看內(nèi)核日志）。

如果klogd進(jìn)程意外退出，還能直接讀內(nèi)核緩沖區(qū)：

# 把緩沖區(qū)日志存到文件dmesg > kernel_bug.log# 或?qū)崟r(shí)讀?。ò碈trl+C停止）cat/proc/kmsg > kernel_bug.log

2.系統(tǒng)崩潰卡死：3種“救命”方法

如果機(jī)器完全凍住，無(wú)法輸入命令，試試這3招：

?應(yīng)急方案：手抄屏幕日志（或拍照），重啟后整理。若日志滾屏太快，可重啟時(shí)加vga=791（高分辨率模式）顯示更多內(nèi)容（需開(kāi)啟vesafb驅(qū)動(dòng)，早期啟動(dòng)階段的bug無(wú)效）；

?提前準(zhǔn)備：用串口控制臺(tái)（參考文檔Documentation/admin-guide/serial-console.rst）——把兩臺(tái)機(jī)器用串口線(xiàn)連接，另一臺(tái)用Minicom等工具捕獲日志，適合長(zhǎng)期調(diào)試；

?專(zhuān)業(yè)方案：開(kāi)啟Kdump（內(nèi)核崩潰轉(zhuǎn)儲(chǔ)）——提前配置后，崩潰時(shí)會(huì)通過(guò)kexec啟動(dòng)備用內(nèi)核，從內(nèi)存中提取日志（具體看Documentation/admin-guide/kdump/gdbmacros.txt）。

三、核心步驟：精準(zhǔn)定位bug的代碼行

拿到Oops日志后，下一步是找到“具體哪行代碼出了問(wèn)題”。文檔推薦兩種工具，gdb最常用，objdump可備用。

1.首選工具：gdb（需開(kāi)啟調(diào)試信息）

gdb能直接把Oops中的內(nèi)存地址，翻譯成“文件名+行號(hào)”——但前提是內(nèi)核編譯時(shí)開(kāi)啟了**CONFIG_DEBUG_INFO**（調(diào)試信息）。

步驟1：開(kāi)啟內(nèi)核調(diào)試信息

在kernel源碼目錄下，執(zhí)行命令開(kāi)啟配置：

# 關(guān)閉COMPILE_TEST，開(kāi)啟DEBUG_KERNEL和DEBUG_INFO./scripts/config -d COMPILE_TEST -e DEBUG_KERNEL -e DEBUG_INFO# 重新編譯內(nèi)核（生成帶調(diào)試信息的vmlinux文件）make vmlinux

步驟2：用gdb定位代碼

根據(jù)Oops日志中的關(guān)鍵信息（EIP地址或函數(shù)偏移），用gdb解析：

?情況1：有EIP地址（比如日志中EIP: 0060:[]）：

gdbvmlinux # 加載帶調(diào)試信息的內(nèi)核文件(gdb) l *0xc021e50e # 查看該地址對(duì)應(yīng)的代碼

?情況2：有函數(shù)偏移（比如日志中EIP is at vt_ioctl+0xda8/0x1482）：

gdbvmlinux(gdb) l *vt_ioctl+0xda8 # 查看vt_ioctl函數(shù)偏移0xda8的代碼# 輸出會(huì)直接指向文件和行號(hào)，比如：# 0x1888 is in vt_ioctl (drivers/tty/vt/vt_ioctl.c:293)

步驟3：模塊級(jí)定位

如果bug在加載的模塊中（比如日志中dvb_usb_adapter_frontend_exit+0x3a/0x70 [dvb_usb]），直接加載模塊文件解析：

# 加載dvb-usb模塊的.o文件gdb drivers/media/usb/dvb-usb/dvb-usb.o(gdb) l *dvb_usb_adapter_frontend_exit+0x3a # 定位模塊內(nèi)代碼

2.備用工具：objdump（無(wú)調(diào)試信息也能用）

如果沒(méi)開(kāi)啟CONFIG_DEBUG_INFO，或只有模塊文件，可用objdump反匯編代碼，間接定位問(wèn)題。

基本用法（查看帶源碼的反匯編）

# -r：顯示重定位信息；-S：混合顯示源碼和匯編；-l：顯示行號(hào)objdump -r -S -l net/dccp/ipv4.o

極端情況：無(wú)源碼時(shí)

如果連源碼都沒(méi)有，可提取Oops日志中“Code:”后的字節(jié)碼，手動(dòng)反匯編：

1.把Code:后的字節(jié)（比如44 24 04 e8 6f ...）存到foo.s文件：

.text.globl foofoo:  .byte0x44,0x24,0x04,0xe8,0x6f, ... # 替換成實(shí)際字節(jié)

1.編譯并反匯編：

gcc-c -o foo.o foo.sobjdump --disassemble foo.o # 查看匯編代碼，推斷邏輯

1.簡(jiǎn)化操作：用內(nèi)核自帶腳本scripts/decodecode自動(dòng)處理（支持多架構(gòu)）。

四、報(bào)告bug：讓維護(hù)者快速接手

定位到bug后，若自己無(wú)法修復(fù)，需向上游報(bào)告——關(guān)鍵是“找對(duì)人”，讓負(fù)責(zé)該模塊的維護(hù)者看到。

1.用腳本找維護(hù)者：get_maintainer.pl

內(nèi)核源碼中的scripts/get_maintainer.pl，能直接輸出文件的維護(hù)者、郵件列表：

# 查看drivers/media/usb/gspca/sonixj.c的維護(hù)信息./scripts/get_maintainer.pl --bug -f drivers/media/usb/gspca/sonixj.c

輸出結(jié)果會(huì)包含：

?模塊維護(hù)者（比如Hans Verkuil ）；

?子系統(tǒng)維護(hù)者（比如Mauro Carvalho Chehab ）；

?相關(guān)郵件列表（比如linux-media@vger.kernel.org，模塊專(zhuān)屬列表）；

?內(nèi)核通用列表（linux-kernel@vger.kernel.org）。

2.報(bào)告優(yōu)先級(jí)：先bug tracker，再郵件

?若輸出中有“bug reporting URIs”（bug跟蹤鏈接），優(yōu)先在跟蹤系統(tǒng)提交；

?若無(wú)，發(fā)送郵件到“模塊專(zhuān)屬郵件列表”，并抄送維護(hù)者；

?完全沒(méi)頭緒時(shí)，直接發(fā)linux-kernel@vger.kernel.org（通用列表，覆蓋所有維護(hù)者）。

五、修復(fù)bug：從定位到提交的最后一步

若你有編程能力，可嘗試修復(fù)bug——提交補(bǔ)丁時(shí)，務(wù)必先讀Documentation/process/submitting-patches.rst，遵守內(nèi)核代碼規(guī)范（比如補(bǔ)丁格式、commit信息寫(xiě)法），這能大幅提高補(bǔ)丁被接受的概率。

畢竟開(kāi)源的核心是協(xié)作，你的一個(gè)小補(bǔ)丁，可能讓成千上萬(wàn)臺(tái)Linux機(jī)器更穩(wěn)定～

最后：klogd的小技巧

klogd（內(nèi)核日志守護(hù)進(jìn)程）是調(diào)試的“隱形助手”，注意兩點(diǎn)：

1.用1.3-pl3以上版本的sysklogd包，支持地址自動(dòng)解析；

2.它會(huì)通過(guò)兩種方式解析地址：

?靜態(tài)解析：用System.map文件（內(nèi)核符號(hào)表）；

?動(dòng)態(tài)解析：自動(dòng)獲取加載模塊的符號(hào)表（支持動(dòng)態(tài)調(diào)試模塊bug）；

1.模塊加載/卸載后，可重啟klogd刷新符號(hào)表（具體看klogd手冊(cè)）。

總結(jié)

內(nèi)核bug調(diào)試看似復(fù)雜，但只要跟著“識(shí)別日志→獲取日志→定位代碼→報(bào)告/修復(fù)”的流程走，再借助gdb、get_maintainer.pl等工具，就能從“無(wú)從下手”變成“有條理排查”。

這份指南的所有方法都來(lái)自?xún)?nèi)核官方文檔，權(quán)威且實(shí)用——下次遇到內(nèi)核bug時(shí)，不妨按這個(gè)流程試試，說(shuō)不定你就是解決問(wèn)題的關(guān)鍵人物～

如果有內(nèi)核調(diào)試的經(jīng)驗(yàn)，歡迎在評(píng)論區(qū)分享你的小技巧～