Linux 內核測試和調試（4）

kmemcheck

kmemcheck 是一個動態檢查工具，可以檢測出一些未被初始化的內存（LCTT：內核態使用這些內存可能會造成系統崩潰）並發出警告。它的功能與 Valgrind 類似，只是 Valgrind 運行在用戶態，而 kmemchecke 運行在內核態。編譯內核時加上 CONFIG_KMEMCHECK 選項打開 kmemcheck 調試功能。你可以閱讀 Documentation/kmemcheck.txt 來學習如何配置使用這個功能，以及如何看懂調試結果。

kmemleak

kmemleak 通過類似於垃圾收集器的功能來檢測內核是否有內存泄漏問題。而 kmemleak 與垃圾收集器的不同之處在於前者不會釋放孤兒目標（LCTT：不會再被使用的、應該被釋放而沒被釋放的內存區域），而是將它們列印到 /sys/kernel/debug/kmemleak 文件中。用戶態的 Valgrind 也有一個類似的功能，使用 --leak-check 選項可以檢測並報錯內存泄漏問題，但並不釋放這個孤兒內存。編譯內核時使用 CONFIG_DEBUG_KMEMLEAK 選項打開 kmemcleak 調試功能。閱讀 Documentation/kmemleak.txt 來學習怎麼使用這個工具並讀懂調試結果。

內核調試介面

Linux 內核通過配置選項、調試用的 API、介面和框架來支持動態或靜態的調試。我們現在就好好學習學習這些牛逼的功能，從靜態編譯選項開始講。

調試配置選項：靜態編譯

大部分 Linux 內核以及內核模塊都包含調試選項，你只要在編譯內核或內核模塊的時候添加這個靜態調試選項，程序運行時後就會產生調試信息，並記錄在 dmesg 緩存中。

調試的 API

調試 API 的一個很好的例子是 DMA-debug，用來調試驅動是否錯誤使用了 DMA 提供的 API。它會跟蹤每個設備的映射關係，檢測程序有沒有試圖為一些根本不存在的映射執行「取消映射」操作，檢測代碼建立 DMA 映射後可能產生的「映射丟失」的錯誤。內核配置選項 CONFIG_HAVE_DMA_APT_DEBUG 和 CONFIG_DMA_API_DEBUG 可以為內核提供這個功能。其中，CONFIG_DMA_API_DEBUG 選項啟用後，內核調用 DMA 的 API 的同時也會調用 Debug-dma 介面。舉例來說，當一個驅動調用 dma_map_page() 函數來映射一個 DMA 緩存時，dma_map_page() 會調用debug_dma_map_page() 函數來跟蹤這個緩存，直到驅動調用 dma_unmap_page() 來取消映射。詳細內容請參考使用 DMA 調試 API 檢測潛在的數據污染和內存泄漏問題。

動態調試

動態調試功能就是你可以決定在程序運行過程中是否要 pr_debug(), dev_dbg(), print_hex_dump_debug(), print_hex_dump_bytes() 這些函數正常運行起來。什麼意思？當程序運行過程中出現錯誤時，你可以指定程序列印有針對性的、詳細的調試信息。這功能牛逼極了，我們不再需要為了添加調試代碼定位一個問題，而重新編譯安裝內核。你可以指定 CONDIF_DYNAMIC_DEBUG 選項打開動態調試功能，然後通過 /sys/kernel/debug/dynamic_debug/control 介面指定要列印哪些調試日誌。下面分別列出代碼級別和模塊級別列印日誌的操作方法：

讓 kernel/power/suspend.c 源碼第340行的 pr_debug() 函數列印日誌：

echo 'file suspend.c line 340 +p' > /sys/kernel/debug/dynamic_debug/control

讓內核模塊在載入過程中打開動態調試功能：

使用 modprobe 命令加在模塊時加上 dyndbg='plmft' 選項。

讓內核模塊的動態調試功能在重啟後依然有效：

編輯 /etc/modprobe.d/modname.conf 文件（沒有這個文件就創建一個），添加 dyndbg='plmft' 選項。然而對於哪些通過 initramfs 載入的驅動來說，這個配置基本無效（LCTT：免費奉送點比較高級的知識哈。系統啟動時，需要先讓 initramfs 掛載一個虛擬的文件系統，然後再掛載啟動盤上的真實文件系統。這個虛擬文件系統裡面的文件是 initramfs 自己提供的，也就是說你在真實的文件系統下面配置了 /etc/modprobe.d/modname.conf 這個文件，initramfs 是壓根不去理會的。站在內核驅動的角度看：如果內核驅動在 initramfs 過程中被載入到內核，這個驅動讀取到的 /etc/modprobe.d/modname.conf 是 initramfs 提供的，而不是你編輯的那個。所以會有上述「寫了配置文件後重啟依然無效」的結論）。對於這種刁民，呃，刁驅動，我們需要修改 grub 配置文件，在 kernel 那一行添加 module.dyndbg='plmft' 參數，這樣你的驅動就可以開機啟動動態調試功能了。

想列印更詳細的調試信息，可以使用 dynamic_debug.verbose=1 選項。參考 Documentation/dynamic-debug-howto.txt 文件獲取更多信息。

設置追蹤點

到目前為止，我們介紹了多種動態和靜態調試方法。靜態調試選項和靜態調試鉤子函數（比如 DMA Debug API）需要的編譯過程打開或關閉，導致了一個難過的事實：需要重新編譯安裝內核。而動態編譯功能省去了「重新編譯」這件麻煩事，但是也有不足的地方，就是調試代碼引入了條件變數，用於判斷是否列印調試信息。這種方法可以讓你在程序運行時決定是否列印日誌，但需要執行額外的判斷過程。「追蹤點」代碼只會在程序運行過程中使用「追蹤點」功能才會被觸發。也就是說，「追蹤點」代碼與上述說的兩種方法都不一樣。當用不到它時，它不會運行（LCTT：動態調試的話，代碼每次都需要查看下變數，然後判斷是否需要列印日誌；而「追蹤點」貌似利用某種觸發機制，不需要每次都去查看變數）。當你需要用到它時，程序的代碼會把「追蹤點」代碼包含進去。它不會添加任何條件變數來增加系統的運行負擔。

詳細信息請參考布置追蹤代碼的小技巧。

「追蹤點」的原理

追蹤點使用「跳躍標籤」，這是一種使用分支跳轉的編碼修正（code modification）技術。

當關閉追蹤點的時候，其偽代碼看起來時這樣的：

[ code1 ]
nop
back:
[ code2 ]
return;
tracepoint:
[ tracepoint code ]
jmp back;

當打開追蹤點的時候，其偽代碼看起來時這樣的：（注意追蹤點代碼出現的位置）

[ code1 ]
jmp tracepoint
back:
[ code2 ]
return;
tracepoint:
[ tracepoint code ]
jmp back;

（LCTT：咳咳，解釋解釋上面兩段偽代碼吧，能看懂的大神請忽略這段注釋。不使用追蹤點時，代碼運行過程是：code1->code2->return結束；使用追蹤點時，代碼運行過程是：code1->跳到tracepoint code執行調試代碼->跳回code2->return結束。兩段代碼的唯一區別就是第二行，前者為 nop（不做任何操作），後者為 jmp tracepoint （跳到調試代碼）。）

Linux 電源管理子系統的測試

使用靜態調試、動態調試和追蹤調試技術，我們來跑一下磁碟的電源管理測試。當系統被掛起時，內核會為磁碟創建一個休眠鏡像，使磁碟進入休眠模式，當系統重新被喚醒時，內核又利用這個休眠鏡像重新喚醒磁碟。

設置掛起設備與喚醒設備需要的時間：

echo 1 > /sys/power/pm_print_times

以 reboot 模式掛起磁碟：

echo reboot > /sys/power/disk
echo disk > /sys/power/state

以 shutdown 模式掛起磁碟 —— 與 reboot 模式一樣，只是重新喚醒磁碟的話還需要電源提供。

echo shutdown > /sys/power/disk
echo disk > /sys/power/state

以 platform 模式掛起磁碟 —— 能測試更多內容，比如 BIOS 掛起和喚醒，會涉及到 ACPI 功能。我們推薦你使用這種方式，把 BIOS 也拉下水陪你玩掛起和喚醒遊戲。

echo platform > /sys/power/disk
echo disk > /sys/power/state

via:http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,3

譯者：bazz2 校對：校對者ID

本文由 LCTT 原創翻譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive