內核是Linux系統的“心臟”——一旦它出bug，小則功能異常，大則系統崩潰、死機。但內核bug往往藏在百萬行代碼中，想快速定位、修復絕非易事。

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

一、先看懂內核的“求救信號”：棧跟蹤與Oops信息

當內核遇到bug時，不會“沉默”——它會輸出棧跟蹤（stack dump）日志，告訴你“哪里出了問題”。這類日志通常分兩種場景：

1.常見的“警告型”日志（WARNING）

比如文檔中給出的例子，內核會明確標出出錯的CPU、進程、代碼位置：

------------[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: # 函數調用棧，記錄bug觸發時的代碼執行路徑[] ? dump_stack+0x44/0x64[] ? __warn+0xfa/0x120[] ? module_put+0x57/0x70 # 關鍵：出錯函數及偏移...

2.嚴重的“崩潰型”日志（Oops/BUG）

如果bug導致內核無法繼續運行，會輸出帶“BUG”或“Oops”的日志，比如空指針引用：

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

3.日志中的“模塊標記”要注意

日志里“Modules linked in”后的模塊名，會帶特殊標記，暗示模塊狀態：

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

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

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

?Tainted: P WC O：內核被“污染”（比如加載了非開源模塊，影響調試）。

二、別讓關鍵日志溜走：找到Oops信息的3種場景

想定位bug，首先得拿到完整的Oops日志——內核會把日志存在不同地方，分場景獲?。?/span>

1.系統還能操作：從常規日志文件拿

內核默認通過klogd把日志傳給syslogd，存到這些位置：

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

?systemd系統：用journalctl命令查看（比如journalctl -k只看內核日志）。

如果klogd進程意外退出，還能直接讀內核緩沖區：

# 把緩沖區日志存到文件dmesg > kernel_bug.log# 或實時讀取（按Ctrl+C停止）cat/proc/kmsg > kernel_bug.log

2.系統崩潰卡死：3種“救命”方法

如果機器完全凍住，無法輸入命令，試試這3招：

?應急方案：手抄屏幕日志（或拍照），重啟后整理。若日志滾屏太快，可重啟時加vga=791（高分辨率模式）顯示更多內容（需開啟vesafb驅動，早期啟動階段的bug無效）；

?提前準備：用串口控制臺（參考文檔Documentation/admin-guide/serial-console.rst）——把兩臺機器用串口線連接，另一臺用Minicom等工具捕獲日志，適合長期調試；

?專業方案：開啟Kdump（內核崩潰轉儲）——提前配置后，崩潰時會通過kexec啟動備用內核，從內存中提取日志（具體看Documentation/admin-guide/kdump/gdbmacros.txt）。

三、核心步驟：精準定位bug的代碼行

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

1.首選工具：gdb（需開啟調試信息）

gdb能直接把Oops中的內存地址，翻譯成“文件名+行號”——但前提是內核編譯時開啟了**CONFIG_DEBUG_INFO**（調試信息）。

步驟1：開啟內核調試信息

在kernel源碼目錄下，執行命令開啟配置：

# 關閉COMPILE_TEST，開啟DEBUG_KERNEL和DEBUG_INFO./scripts/config -d COMPILE_TEST -e DEBUG_KERNEL -e DEBUG_INFO# 重新編譯內核（生成帶調試信息的vmlinux文件）make vmlinux

步驟2：用gdb定位代碼

根據Oops日志中的關鍵信息（EIP地址或函數偏移），用gdb解析：

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

gdbvmlinux # 加載帶調試信息的內核文件(gdb) l *0xc021e50e # 查看該地址對應的代碼

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

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

步驟3：模塊級定位

如果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 # 定位模塊內代碼

2.備用工具：objdump（無調試信息也能用）

如果沒開啟CONFIG_DEBUG_INFO，或只有模塊文件，可用objdump反匯編代碼，間接定位問題。

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

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

極端情況：無源碼時

如果連源碼都沒有，可提取Oops日志中“Code:”后的字節碼，手動反匯編：

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

.text.globl foofoo:  .byte0x44,0x24,0x04,0xe8,0x6f, ... # 替換成實際字節

1.編譯并反匯編：

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

1.簡化操作：用內核自帶腳本scripts/decodecode自動處理（支持多架構）。

四、報告bug：讓維護者快速接手

定位到bug后，若自己無法修復，需向上游報告——關鍵是“找對人”，讓負責該模塊的維護者看到。

1.用腳本找維護者：get_maintainer.pl

內核源碼中的scripts/get_maintainer.pl，能直接輸出文件的維護者、郵件列表：

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

輸出結果會包含：

?模塊維護者（比如Hans Verkuil ）；

?子系統維護者（比如Mauro Carvalho Chehab ）；

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

?內核通用列表（linux-kernel@vger.kernel.org）。

2.報告優先級：先bug tracker，再郵件

?若輸出中有“bug reporting URIs”（bug跟蹤鏈接），優先在跟蹤系統提交；

?若無，發送郵件到“模塊專屬郵件列表”，并抄送維護者；

?完全沒頭緒時，直接發linux-kernel@vger.kernel.org（通用列表，覆蓋所有維護者）。

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

若你有編程能力，可嘗試修復bug——提交補丁時，務必先讀Documentation/process/submitting-patches.rst，遵守內核代碼規范（比如補丁格式、commit信息寫法），這能大幅提高補丁被接受的概率。

畢竟開源的核心是協作，你的一個小補丁，可能讓成千上萬臺Linux機器更穩定～

最后：klogd的小技巧

klogd（內核日志守護進程）是調試的“隱形助手”，注意兩點：

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

2.它會通過兩種方式解析地址：

?靜態解析：用System.map文件（內核符號表）；

?動態解析：自動獲取加載模塊的符號表（支持動態調試模塊bug）；

1.模塊加載/卸載后，可重啟klogd刷新符號表（具體看klogd手冊）。

總結

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

這份指南的所有方法都來自內核官方文檔，權威且實用——下次遇到內核bug時，不妨按這個流程試試，說不定你就是解決問題的關鍵人物～

如果有內核調試的經驗，歡迎在評論區分享你的小技巧～