kdump的出現(基於嵌入式Linux的核心錯誤跟蹤技術)
隨著嵌入式Linux系統的廣泛應用,對系統的可靠性提出了更高的要求,尤其是涉及到生命財產等重要領域,要求系統達到安全完整性等級3級以上[1],故障率(每小時出現危險故障的可能性)為10-7以下,相當於系統的平均故障間隔時間(MTBF)至少要達到1141 年以上,因此提高系統可靠性已成為一項艱鉅的任務。對某公司在工業領域14 878個控制器系統的應用調查表明,從2004 年初到2007 年9月底,隨著硬軟體的不斷改進,根據錯誤報告統計的故障率已降低到2004年的五分之一以下,但查詢錯誤的時間卻增加到原來的3倍以上
這種解決問題所需時間呈上升的趨勢固然有軟體問題,但缺乏必要的手段以輔助解決問題才是主要的原因。通過對故障的統計跟蹤發現,難以解決的軟體錯誤
和從發現到解決耗時較長的軟體錯誤都集中在作業系統的核心部分,這其中又有很大比例集中在驅動程式部分[2]。因此,錯誤跟蹤技術被看成是提高系統安全完
整性等級的一個重要措施[1],大多數現代作業系統均為發展提供了作業系統核心“崩潰轉儲”機制,即在軟體系統宕機時,將
基於Linux作業系統核心的崩潰轉儲機制近年來有以下幾種:
(1) LKCD(Linux Kernel Crash Dump)機制[3];
(2) KDUMP(Linux Kernel Dump)機制[4];
(3) KDB機制[5];
(4) KGDB機制[6]。
綜合上述幾種機制可以發現,這四種機制之間有以下三個共同點:
(1) 適用於為運算資源豐富、儲存空間充足的應用場合;
(2) 發生系統崩潰後恢復時間無嚴格要求;
(3) 主要針對較通用的硬體平臺,如X86平臺。
在嵌入式應用場合想要直接使用上列機制中的某一種,卻遇到以下三個難點無法解決:
(1) 儲存空間不足
嵌入式系統一般採用Flash 作為儲存器 ,而Flash容量有限,且可能遠遠小於嵌入式系統中的記憶體容量。因此將全部記憶體內容儲存到Flash不可行。
(2) 記錄時間要求儘量短
嵌入式系統一般有復位響應時間儘量短的要求,有的嵌入式作業系統復位重啟時間不超過2s,而上述幾種可用於Linux系統的核心崩潰轉儲機制耗時均不可能在30s內。寫Flash的操作也很耗時間,實驗顯示,寫2MB資料到Flash耗時達到400ms之多。
(3) 要求能夠支援特定的硬體平臺
嵌入式系統的硬體多種多樣,上面提到的四種機制均是針對X86平臺提供了較好的支援,而對於其他體系的硬體支援均不成熟。
由於這些難點的存在,要將上述四種核心崩潰轉儲機制中的一種移植到特定的嵌入式應用平臺是十分困難的。因此,針對上述嵌入式系統的三個特點,本 文介紹一種基於特定平臺的嵌入式Linux核心崩潰資訊記錄機制LCRT(Linux Crash Record and Trace),為定位嵌入式Linux系統中軟體故障和解決軟體故障提供輔助手段。
1 Linux核心崩潰的分析
分析Linux核心對於執行期間各種“陷阱”的處理可以得知,Linux核心對於應用程式導致的錯誤可以予以監控,在應用程式發生除零、記憶體訪 問越界、緩衝區溢位等錯誤時,Linux核心的異常處理例程可以對這些由應用程式引起的異常情況予以處理。當應用程式產生不可恢復的錯誤時,Linux內 核可以僅僅終止產生錯誤的應用程式,其他應用程式仍然可以正常執行。
如果Linux核心本身或者新開發的Linux核心模組存在bug,產生了“除零”,“記憶體訪問越界”、“緩衝區溢位”等錯誤,同樣會由
Linux核心的異常處理例程來處理。Linux核心通過在異常處理程式中判斷,如果發現是“嚴重的不可恢復”的核心異常,則會導致“核心恐慌”
(kernel panic),即Linux核心崩潰。圖1所示為Linux核心對異常情況的處理流程。
2 LCRT機制的設計與實現
通過對Linux核心程式碼的分析可知,Linux核心本身提供了一種“核心通知機制”[7-8],並預定義了“核心事件通知鏈”,使得 Linux核心擴充套件開發人員可以通過這些預定義的核心事件通知鏈在特定的核心事件發生時執行附加的處理流程。通過對Linux核心原始碼的研究發現,對於 上文中提到的“嚴重不可恢復的核心異常”,預定義了一個通知鏈和通知點,使得在發生Linux核心崩潰之後,可以在Linux核心的panic函式中預定 義的一個“核心崩潰通知鏈”[7]上掛接LCRT機制來獲得Linux核心崩潰現場的一些資訊並記錄到非易失性儲存器中,以便分析引起Linux核心崩潰 的原因。
2.1 設計要點
LCRT機制的設計和實現基於如下特定的機制:
(1) 編譯器選項與核心依賴
Linux核心及相應的驅動程式都採用GNU[9]的開源編譯器GCC[9]編譯,為了結合LCRT機制方便地提取資訊和記錄資訊,需要採用特 定的GCC編譯器選項來編譯Linux核心和相關的驅動程式以及應用程式。用到的選項為:-mpoke-function-name[9]。使用這個選項 編譯出的二進位制程式中可以包含C語言函式名稱的資訊,以方便函式呼叫鏈回溯時記錄資訊的可讀性。
(2) Linux核心notify_chain機制[8]
Linux核心提供“通知鏈”功能,並預定義了一個核心崩潰通知鏈,在Linux核心的異常處理例程中判斷出系統進入“不可恢復”狀態時,會沿預定義的通知鏈順序呼叫註冊到相應鏈中的通知函式。
(3) 函式呼叫的棧佈局
Linux核心的絕大部分由C語言實現,而且C語言也多用來進行Linux核心開發。Linux核心及使用LKM擴充套件而加入Linux核心執行 環境的程式碼是有規律可循的,這些程式碼在執行過程中產生的棧佈局和這些規律的程式碼相關聯。例如,這些函式在執行函式之前會儲存本函式呼叫後的返回地址、本函 數被呼叫時傳遞過來的引數及呼叫本函式的函式所擁有的棧幀的棧底。
2.2 LCRT機制的設計思想
LCRT機制分為Linux核心模組[8]部分和Linux使用者程式部分。核心模組部分的設計採用了Linux核心模組的模式而不是直接修改 Linux核心。這樣的設計降低了Linux核心和LCRT機制之間的耦合度,同時滿足了Linux核心和LCRT機制獨立升級完善的便利性。使用者程式部 分完成從非易失性儲存器中讀取、清除LCRT機制儲存的資訊等相關功能。
在LCRT機制的設計中,針對嵌入式系統的特點,其設計決策有:
(1) 將對於解決和定位問題最具輔助意義的函式呼叫關係鏈記錄下來。
(2) 為了不佔用過多的儲存空間,有選擇性地將函式呼叫序列上的函式各自用到的棧內容儲存起來,而不是儲存全部內容。
(3) 將記錄的資訊儲存到非易失性儲存器中,這樣既達到了掉電儲存的目的、又縮短了寫入時間。
LCRT機制的設計包括以下五個方面。
(1) 設計Linux核心模組、動態地載入LCRT機制、儘量少地修改Linux核心程式碼。
(2)在相應、預定義的Linux核心通知鏈上掛接LCRT的通知函式。
(3) 在LCRT機制的通知處理函式中進行堆疊回溯得到函式呼叫資訊。
(4) 記錄回溯到的函式呼叫資訊和堆疊空間內容到非易失性儲存器。
(5) 開發使用者空間的工具 ,可以從非易失性儲存器中讀取儲存的資訊。
2.3 LCRT機制的實現
LCRT機制的實現可參照2.2節的設計思想,分步予以實現。限於篇幅,本文不過多涉及Linux核心模組的原理和實現相關的細節,僅僅給出LCRT機制的核心模組實現虛擬碼。用虛擬碼描述LCRT機制的載入函式如下:
int lcrt_init(void)
{
printk("Registering my__panic notifier.n");
^_nvram_ptr=(volatile unsigned char *)ioremap_
nocache (BT_NVRAM_BASE,BT_NVRAM_LENGTH);
^_nvram_index+=sizeof(struct ^_info);
*)^_nvram_ptr,BT_NVRAM_LENGTH);
notifier_chain_register(&panic_notifier_list,&my_
panic_block);
return 0;
}
LCRT機制的通知處理函式完成函式呼叫關係回溯、得到函式名稱、函式棧內容等工作,限於篇幅,在這裡用下面虛擬碼說明:
void ll_^_information(struct pt_regs *pr)
{
變數定義等初始化工作
do {
reglist=*(unsigned long *)(*myfp-8);
//從函式棧幀的頂部獲取函式開始執行時儲存的暫存器資訊
//從函式的程式碼區中取得函式的名稱
//從函式的棧幀裡取出函式執行函式體程式碼之前儲存的函式引數資訊
//從本函式的棧幀中得到呼叫本函式的程式碼所在位置和呼叫本函式的函式棧幀的棧底
}while(直到函式呼叫鏈的鏈頭);
//取得函式呼叫棧幀的內容
//填充資訊記錄的記錄頭部
//將上面的迴圈中取得的資訊儲存到非易失性儲存器中
write_to_nvram((void *)^_nvram_ptr,&^_record_header,sizeof(^_info_t));
}
3 驗證*估LCRT機制
3.1 部署LCRT機制
部署LCRT機制,使LCRT機制發揮作用前需要做的相關工作有:
(1)針對目標Linux核心編譯LCRT機制的Linux核心模組部分;
(2) 將LCRT機制的核心模組部分載入Linux核心。
3.2 實驗結果
為了實驗LCRT機制的作用效果,構造一個會造成Linux核心崩潰的裝置驅動模組 ,記這個核心驅動模組為bugguy.ko,列出如下所示的bugguy.ko中會引起Linux核心崩潰的程式碼如下所示:
irqreturn_t my_timer_interrupt(int irq,void *dev_id,struct pt_regs* regs)
{
確認硬體狀態並清除中斷狀態
if(ujiffies > 5000 ) {
void * ill_pointer=NULL ;
*(unsigned long *)ill_pointer=0;
}
else {
ujiffies++;
}
return IRQ_HANDLED ;
}
說明:用黑體標出的程式碼即為產生bug的程式碼
從上面的程式碼可以看出,這個錯誤是對空指標進行解析而造成的。在一箇中斷處理函式中如果發生對空指標的解析,將會引起Linux核心的崩潰。在
部署完成LCRT機制的嵌入式linux系統上將這個bugguy.ko載入Linux核心,使得會引起Linux核心崩潰的中斷處理程式得以運
行,LCRT機制可以將相關的資訊儲存到非易失性儲存器中,在系統復位後,通過LCRT機制的使用者空間工具,可以將儲存的資訊讀取出來。實驗結果顯示,可
以得到如圖2所示的函式呼叫鏈資訊。
圖2標註即為會引起Linux核心崩潰的錯誤程式碼的中斷處理函式即真正引起系統宕機的“罪魁禍首”。而記錄下的所有資訊僅僅佔用了不到1KB的 儲存空間,寫入非易失性儲存器所耗用的時間控制在50ms以內。在使用少量空間和少量時間的情況下,所記錄下的資訊對於查詢問題和解決問題都有較大的幫 助。
實驗結果表明,在LCRT機制的作用下,可以快速地定位到嵌入式Linux系統中隱藏的可能會導致系統宕機的軟體缺陷。這就為後續的故障解決和軟體完善提供了關鍵的輔助資訊。對嵌入式Linux核心而言,即是為提高Linux核心的穩定性和可靠性提供了幫助。
在基於ARM的嵌入式Linux應用中,開發LCRT機制來記錄系統核心發生崩潰時引起崩潰的函式呼叫鏈和棧資訊到非易失性儲存器中,截至目前 為止,LCRT機制可以記錄基於ARM的嵌入式Linux核心發生崩潰時的函式呼叫鏈資訊,可直接得到函式名稱、函式呼叫鏈中單個函式被呼叫時的引數資訊 以及函式呼叫鏈中的函式各自的棧幀資訊。這些記錄下來的資訊對於完善和發展基於ARM的嵌入式Linux應用具有重要的輔助意義。