2. 程式人生 > >Linux核心Crash分析

Linux核心Crash分析

阿新 • • 發佈：2018-11-23

  在工作中經常會遇到一些核心crash的情況，本文就是根據核心出現crash後的列印資訊，對其進行了分析，使用的核心版本為：Linux2.6.32。

       每一個程序的生命週期內，其生命週期的範圍為幾毫秒到幾個月。一般都是和核心有互動，例如使用者空間程式使用系統呼叫進入核心空間。這時使用的不再是使用者空間的棧空間，使用對應的核心棧空間。對每一個程序來說，Linux核心都會把兩個不同的資料結構緊湊的存放在一個單獨為程序分配的儲存空間中：一個是核心態的程序堆疊，另一個是緊挨程序描述符的資料結構thread_info,叫執行緒描述符。核心的堆疊大小一般為8KB，也就是8192個位元組，佔用兩個頁。在Linux-2.6.32核心中thread_info.h檔案中有對核心堆疊的定義： 

  1. #define THREAD_SIZE 8192

          在Linux核心中使用下面的聯合結構體表示一個程序的執行緒描述符和核心棧，在核心中檔案include/linux/sched.

  1. union thread_union {
  2. struct thread_info thread_info;
  3. unsigned long stack[THREAD_SIZE/sizeof(long)];
  4. };

          該結構是一個聯合體，我們在C語言書上看到過關於union的解釋，在在C Programming Language 一書中對於聯合體是這麼描述的：

1) 聯合體是一個結構；

2) 它的所有成員相對於基地址的偏移量都為0；

3) 此結構空間要大到足夠容納最"寬"的成員；

4) 其對齊方式要適合其中所有的成員；

         通過上面的描述可知，thread_union結構體的大小為8192個位元組。也就是stack陣列的大小，型別是unsigned long類 型。由於聯合體中的成員變數都是佔用同一塊記憶體區域，所以，在平時寫程式碼時總有一個概念，對一個聯合體的例項只能使用其中一個成員變數，否則會把原先變數 給覆蓋掉，這句話如果正確的話，必須要有一個前提假設，成員佔用的位元組數相同，當成員所佔的位元組數不同時，只會覆蓋相應的位元組。對於thread_union聯合體，我們是可以同時訪問這兩個成員，只要能夠正確獲取到兩個成員變數的地址。

         在核心中的某一個程序使用了過多的棧空間時，核心棧就會溢位到thread_info部分，這將導致嚴重的問題（系統重啟），例如，遞迴呼叫的層次太深；在函式內定義的資料結構太大。

圖：程序中thread_info    task_struct和核心棧中的關係

         下面我們看一下thread_info的結構體:

  1. struct thread_info {
  2. unsigned long flags; /* 底層標誌，*/
  3. int preempt_count; /* 0 => 可搶佔, <0 => bug */
  4. mm_segment_t addr_limit; /* 程序地址空間 */
  5. struct task_struct *task; /*當前程序的task_struct指標 */
  6. struct exec_domain *exec_domain; /*執行區間 */
  7. __u32 cpu; /* 當前cpu */
  8. __u32 cpu_domain; /* cpu domain */
  9. struct cpu_context_save cpu_context; /* cpu context */
  10. __u32 syscall; /* syscall number */
  11. __u8 used_cp[16]; /* thread used copro */
  12. unsigned long tp_value;
  13.  
  14. struct crunch_state crunchstate;
  15.  
  16. union fp_state fpstate __attribute__((aligned(8)));
  17. union vfp_state vfpstate;
  18. #ifdef CONFIG_ARM_THUMBEE
  19. unsigned long thumbee_state; /* ThumbEE Handler Base register */
  20. #endif
  21. struct restart_block restart_block; /*用於實現訊號機制*/
  22. };

 PS：（1）flag 用於儲存各種特定的程序標誌，最重要的兩個是：TIF_SIGPENDING，如果程序有待處理的訊號就置位，TIF_NEED_RESCHED表示程序應該需要排程器選擇另一個程序替換本程序執行。

         結合上面的知識，看下當核心列印堆疊資訊時，都列印了上面資訊。下面的列印資訊是工作中遇到的一種情況，列印了核心的堆疊資訊，PC指標在dev_get_by_flags中，不能訪問的核心虛地址為45685516，核心中一般可訪問的地址都是以0xCXXXXXXX開頭的地址。

  1. Unable to handle kernel paging request at virtual address 45685516
  2. pgd = c65a4000
  3. [45685516] *pgd=00000000
  4. Internal error: Oops: 1 [#1]
  5. last sysfs file: /sys/devices/form/tpm/cfg_l3/l3_rule_add
  6. Modules linked in: splic mmp(P)
  7. CPU: 0 Tainted: P (2.6.32.11 #42)
  8. PC is at dev_get_by_flags+0xfc/0x140
  9. LR is at dev_get_by_flags+0xe8/0x140
  10. pc : [<c06bee24>] lr : [<c06bee10>] psr: 20000013
  11. sp : c07e9c28 ip : 00000000 fp : c07e9c64
  12. r10: c6bcc560 r9 : c646a220 r8 : c66a0000
  13. r7 : c6a00000 r6 : c0204e56 r5 : 30687461 r4 : 45685516
  14. r3 : 00000000 r2 : 00000010 r1 : c0204e56 r0 : ffffffff
  15. Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
  16. Control: 0005397f Table: 065a4000 DAC: 00000017
  17. Process swapper (pid: 0, stack limit = 0xc07e8270)
  18. Stack: (0xc07e9c28 to 0xc07ea000)
  19. 9c20: c0204e56 c6a00000 45685516 c69ffff0 c69ffff0 c69ffff0
  20. 9c40: c6a00000 30687461 c66a0000 c6a00000 00000007 c64b210c c07e9d24 c07e9c68
  21. 9c60: c071f764 c06bed38 c66a0000 c66a0000 c6a00000 c6a00000 c66a0000 c6a00000
  22. 9c80: c07e9cfc c07e9c90 c03350d4 c0334b2c 00000034 00000006 00000100 c64b2104
  23. 9ca0: 0000c4fb c0243ece c66a0000 c0beed04 c033436c c646a220 c07e9cf4 00000000
  24. 9cc0: c66a0000 00000003 c0bee8e8 c0beed04 c07e9d24 c07e9ce0 c06e4f5c 00004c68
  25. 9ce0: 00000000 faa9fea9 faa9fea9 00000000 00000000 c6bcc560 c0335138 c646a220
  26. 9d00: c66a0000 c64b2104 c085ffbc c66a0000 c0bee8e8 00000000 c07e9d54 c07e9d28
  27. 9d20: c071f9a0 c071ebc0 00000000 c071ebb0 80000000 00000007 c67fb460 c646a220
  28. 9d40: c0bee8c8 00000608 c07e9d94 c07e9d58 c002a100 c071f84c c0029bb8 80000000
  29. 9d60: c07e9d84 c0beee0c c0335138 c66a0000 c646a220 00000000 c4959800 c4959800
  30. 9d80: c67fb460 00000000 c07e9dc4 c07e9d98 c078f0f4 c0029bc8 00000000 c0029bb8
  31. 9da0: 80000000 c07e9dbc c6b8d340 c66a0520 00000000 c646a220 c07e9dec c07e9dc8
  32. 9dc0: c078f450 c078effc 00000000 c67fb460 c6b8d340 00000000 c67fb460 c64b20f2
  33. 9de0: c07e9e24 c07e9df0 c078fb60 c078f130 00000000 c078f120 80000000 c0029a94
  34. 9e00: 00000806 c6b8d340 c0bee818 00000001 00000000 c4959800 c07e9e64 c07e9e28
  35. 9e20: c002a030 c078f804 c64b2070 00000000 c64b2078 ffc45000 c64b20c2 c085c2dc
  36. 9e40: 00000000 c085c2c0 00000000 c0817398 00086c2e c085c2c4 c07e9e9c c07e9e68
  37. 9e60: c06c2684 c0029bc8 00000001 00000040 00000000 c085c2dc c085c2c0 00000001
  38. 9e80: 0000012c 00000040 c085c2d0 c0bee818 c07e9ed4 c07e9ea0 c00284e0 c06c2608
  39. 9ea0: bf00da5c 00086c30 00000000 00000001 c097e7d4 c07e8000 00000100 c08162d8
  40. 9ec0: 00000002 c097e7a0 c07e9f14 c07e9ed8 c00283d0 c0028478 56251311 00023c88
  41. 9ee0: c07e9f0c 00000003 c08187ac 00000018 00000000 01000000 c07ebc70 00023cbc
  42. 9f00: 56251311 00023c88 c07e9f24 c07e9f18 c03391e8 c0028348 c07e9f3c c07e9f28
  43. 9f20: c0028070 c03391b0 ffffffff 0000001f c07e9f94 c07e9f40 c002d4d0 c0028010
  44. 9f40: 00000000 00000001 c07e9f88 60000013 c07e8000 c07ebc78 c0868784 c07ebc70
  45. 9f60: 00023cbc 56251311 00023c88 c07e9f94 c07e9f98 c07e9f88 c025c3e4 c025c3f4
  46. 9f80: 60000013 ffffffff c07e9fb4 c07e9f98 c025c578 c025c3cc 00000000 c0981204
  47. 9fa0: c0025ca0 c0d01140 c07e9fc4 c07e9fb8 c0032094 c025c528 c07e9ff4 c07e9fc8
  48. 9fc0: c0008918 c0032048 c0008388 00000000 00000000 c0025ca0 00000000 00053975
  49. 9fe0: c0868834 c00260a4 00000000 c07e9ff8 00008034 c0008708 00000000 00000000
  50. Backtrace:
  51. [<c06bed28>] (dev_get_by_flags+0x0/0x140) from [<c071f764>] (arp_process+0xbb4/0xc74)
  52. r7:c64b210c r6:00000007 r5:c6a00000 r4:c66a0000

 

         （1）首先，看看這段堆疊資訊是在核心中那個檔案中打印出來的，在fault.c檔案中，__do_kernel_fault函式，在上面的列印中Unable to handle kernel paging request at virtual address 45685516，該地址是核心空間不可訪問的地址。

  1. static void __do_kernel_fault(struct mm_struct *mm, unsigned long addr, unsigned int fsr, struct pt_regs *regs)
  2. {
  3. /*
  4. * Are we prepared to handle this kernel fault?
  5. */
  6. if (fixup_exception(regs))
  7. return;
  8. /*
  9. * No handler, we'll have to terminate things with extreme prejudice.
  10. */
  11. bust_spinlocks(1);
  12. printk(KERN_ALERT
  13. "Unable to handle kernel %s at virtual address %08lx\n",
  14. (addr < PAGE_SIZE) ? "NULL pointer dereference" :"paging request", addr);
  15. show_pte(mm, addr);
  16. die("Oops", regs, fsr);
  17. bust_spinlocks(0);
  18. do_exit(SIGKILL);
  19. }

 （2） 對於下面的兩個資訊，在函式show_pte中進行了列印，下面的列印涉及到了頁全域性目錄，頁表的知識，暫時先不分析，後續補上。

  1. pgd = c65a4000
  2. [45685516] *pgd=00000000
  3.  
  4. void show_pte(struct mm_struct *mm, unsigned long addr)
  5. {
  6. pgd_t *pgd;
  7. if (!mm)
  8. mm = &init_mm;
  9.  
  10. printk(KERN_ALERT "pgd = %p\n", mm->pgd);
  11. pgd = pgd_offset(mm, addr);
  12. printk(KERN_ALERT "[%08lx] *pgd=%08lx", addr, pgd_val(*pgd));
  13. ……………………
  14. }

 (3) die函式中呼叫在die函式中取得thread_info結構體的地址。

  1. struct thread_info *thread = current_thread_info();
  2.  
  3. static inline struct thread_info *current_thread_info(void){
  4. register unsigned long sp asm ("sp");
  5. return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
  6. }

 Sp: 0xc07e9c28    通過current_thread_info得到 thread_info的地址

(0xc07e9c28 & 0xffffe000) = 0xC07E8000（thread_info的地址，也就是棧底的地址）

(4)下面的列印資訊在__die函式中列印

  1. Internal error: Oops: 1 [#1]
  2. last sysfs file: /sys/devices/form/tpm/cfg_l2/l2_rule_add
  3. Modules linked in: splic mmp(P)
  4. CPU: 0 Tainted: P (2.6.32.11 #42)
  5. PC is at dev_get_by_flags+0xfc/0x140
  6. LR is at dev_get_by_flags+0xe8/0x140
  7. pc : [<c06bee24>] lr : [<c06bee10>] psr: 20000013
  8. sp : c07e9c28 ip : 00000000 fp : c07e9c64
  9. r10: c6bcc560 r9 : c646a220 r8 : c66a0000
  10. r7 : c6a00000 r6 : c0204e56 r5 : 30687461 r4 : 30687461
  11. r3 : 00000000 r2 : 00000010 r1 : c0204e56 r0 : ffffffff
  12. Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
  13. Control: 0005397f Table: 065a4000 DAC: 00000017
  14. Process swapper (pid: 0, stack limit = 0xc07e8270)
  15. Stack: (0xc07e9c28 to 0xc07ea000)

          函式的呼叫關係：die("Oops", regs, fsr);---à    __die(str, err, thread, regs);

下面是__die函式的定義：

  1. static void __die(const char *str, int err, struct thread_info *thread, struct pt_regs *regs){
  2. struct task_struct *tsk = thread->task;
  3. static int die_counter;
  4. /*Internal error: Oops: 1 [#1]*/
  5. printk(KERN_EMERG "Internal error: %s: %x [#%d]" S_PREEMPT S_SMP "\n",
  6. str, err, ++die_counter);
  7. /*last sysfs file: /sys/devices/form/tpm/cfg_l2/l2_rule_add*/
  8. sysfs_printk_last_file();
  9. /*核心中載入的模組資訊Modules linked in: splic mmp(P) */
  10. print_modules();
  11. /*列印暫存器資訊*/
  12. __show_regs(regs);
  13. /*Process swapper (pid: 0, stack limit = 0xc07e8270) tsk->comm task_struct結構體中的comm表示的是除去路徑後的可執行檔名稱，這裡的swapper為idle程序，程序號為0，建立核心程序init；其中stack limit = 0xc07e8270 指向thread_info的結束地址。*/
  14. printk(KERN_EMERG "Process %.*s (pid: %d, stack limit = 0x%p)\n",
  15. TASK_COMM_LEN, tsk->comm, task_pid_nr(tsk), thread + 1);
  16. /* dump_mem 函式列印從棧頂到當前sp之間的內容*/
  17. if (!user_mode(regs) || in_interrupt()) {
  18. dump_mem(KERN_EMERG, "Stack: ", regs->ARM_sp, THREAD_SIZE + (unsigned long)task_stack_page(tsk));
  19. dump_backtrace(regs, tsk);
  20. dump_instr(KERN_EMERG, regs);
  21. }
  22. }

          在上面的函式中，主要使用了thread_info,task_struct,sp之間的指向關係。task_struct結構體的成員stack是棧底，也是對應thread_info結構體的地址。堆疊資料是從棧底+8K的地方開始向下存的。SP指向的是當前的棧頂。(unsigned long)task_stack_page(tsk)，

#define task_stack_page(task)        ((task)->stack) ，該巨集根據task_struct得到棧底，也就是thread_info地址。

#define task_thread_info(task)       ((struct thread_info *)(task)->stack)，該巨集根據task_struct得到thread_info指標。

（5）dump_backtrace函式

         該函式用於列印函式的呼叫關係。Fp為幀指標，用於追溯程式的方式，方向跟蹤呼叫函式。該函式主要是fp進行檢查，看看能否進行backtrace，如果可以就調用匯編的c_backtrace，在arch/arm/lib/backtrace.S函式中。

  1. static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
  2. {
  3. unsigned int fp, mode;
  4. int ok = 1;
  5.  
  6. printk("Backtrace: ");
  7. if (!tsk)
  8. tsk = current;
  9.  
  10. if (regs) {
  11. fp = regs->ARM_fp;
  12. mode = processor_mode(regs);
  13. } else if (tsk != current) {
  14. fp = thread_saved_fp(tsk);
  15. mode = 0x10;
  16. } else {
  17. asm("mov %0, fp" : "=r" (fp) : : "cc");
  18. mode = 0x10;
  19. }
  20.  
  21. if (!fp) {
  22. printk("no frame pointer");
  23. ok = 0;
  24. } else if (verify_stack(fp)) {
  25. printk("invalid frame pointer 0x%08x", fp);
  26. ok = 0;
  27. } else if (fp < (unsigned long)end_of_stack(tsk))
  28. printk("frame pointer underflow");
  29. printk("\n");
  30. if (ok)
  31. c_backtrace(fp, mode);
  32. }

 （6）dump_instr

根據PC指標和指令mode, 打印出當前執行的指令碼

Code: 0a000008 e5944000 e2545000 0a000005 (e4153010)

核心中函式的呼叫關係

相關推薦

Linux核心Crash分析

  在工作中經常會遇到一些核心crash的情況，本文就是根據核心出現crash後的列印資訊，對其進行了分析，使用的核心版本為：Linux2.6.32。        每一個程序的生命週期內，其生命週期的範圍為幾毫秒到幾個月。一般都是和核心有互動，

Linux核心排程分析（轉，侵刪）

多工 併發和並行 Linux作為一個多工作業系統，必須支援程式的併發執行。 分類 非搶佔式多工 　　　除非任務自己結束，否則將會一直執行。 搶佔式多工（Linux） 這種情況下，由排程程式來決定什麼時候停止一個程序的執行，這個強制的掛起動作即為**“搶佔”**。採用搶佔式多工

linux 核心程式碼分析1 TI am335x

1.     TI AM335x  核心原始碼分析 1.1 Board-am335xevm.c Board-am335xevm.c(./arch/arm/mach-omap2)中開始執行入口： MACHINE_START(A

linux核心原始碼分析-夥伴系統

之前的文章已經介紹了夥伴系統，這篇我們主要看看原始碼中是如何初始化夥伴系統、從夥伴系統中分配頁框，返回頁框於夥伴系統中的。 　　我們知道，每個管理區都有自己的夥伴系統管理屬於這個管理區的頁框，這也說明了，在夥伴系統初始化時，管理區必須要已經存在(初始化完成)

Linux核心原始碼分析--zImage出生實錄（Linux-3.0 ARMv7）

此文為兩年前為好友劉慶敏的書《嵌入式Linux開發詳解--基於AT91RM9200和Linux 2.6》中幫忙寫的章節的重新整理。如有雷同，純屬必然。經作者同意，將我寫的部分重新整理後放入blog中。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

《Linux核心情景分析》經典解說--程序

get_current 使用巨集的原因 ==================== include/asmi386/ current.h 6 13 ==================== 6 static inline struct task_struct * get_current

ioctl配置IP地址 Linux核心實現分析

1 執行flow 本文以Linux kernel3.10版本描述 上圖是《Understanding LINUX NETWORK INTERNALS》一書中對socket的ioctl呼叫的整體flow，本文只對其中SIOCSIFADDR這一個command進行flow

linux核心原始碼分析

本文基於3.18.3核心的分析,nvme裝置為pcie介面的ssd,其驅動名稱為nvme.ko,驅動程式碼在drivers/block/nvme-core.c. 驅動的載入 　　驅動載入實際就是module的載入,而module載入時會對整個module進行初始化,nvme驅動的module初始化函式

linux核心中斷分析

知識要點 一、struct irq_chip、struct irq_desc[]、struct irqaction三者之間的關係 二、Linux核心中中斷的初始化流程、中斷的註冊流程、中斷的執行流程 三、多核cpu的中斷親和力和中斷負載均衡 四、中斷的上半部和下半部 一、s

s3c2410 RTC驅動框架linux核心原始碼分析

實在無聊中就將原來的一些東西整理了一下，自己是個記性不好的人，隔斷時間整理自己，同時也希望可以方便他人。 -------------------------------------------------------------------------------------

Linux核心原始碼分析——Linux核心的入口

Jack：hi，淫龍，在Linux核心的原始碼裡，有幾段彙編程式碼，那幾段程式碼是負責Linux核心引導的。 我：是的。早期的Linux核心引導程式碼只有bootsect.s、setup.s、head.s這3個檔案，這三個檔案都是Linus在1991年左右親手寫的。後來的程

Linux核心原始碼分析--記憶體管理（一、分頁機制）

        Linux系統中分為幾大模組：程序排程、記憶體管理、程序通訊、檔案系統、網路模組；各個模組之間都有一定的聯絡，就像蜘蛛網一樣，所以這也是為什麼Linux核心那麼難理解，因為不知道從哪裡開始著手去學習。很多人會跟著系統上電啟動 BIOS-->bootse

LINUX-核心-中斷分析-中斷向量表（2）-mips

mips中斷概念 在《MIPS體系結構透視》的第5章說到，在MIPS中，中斷、陷阱、系統呼叫和任何可以中斷程式正常執行流的情況全被都被稱為異常。 以上這種統一到“異常”的概念及其邏輯當然會體現在MIPS的異常入口點的設計中，特別如MIPS中斷入口點的引出。

Linux核心原始碼分析--檔案系統（五、Inode.c）

_bmap()         1、_bmap()函式用於把一個檔案資料塊對映到盤塊的處理操作                  因為一個i節點對應一個檔案，所以上面的i節點對映的邏輯塊號就是檔案資料存放的邏輯塊號；i_zone[0]到i_zone[6]是直接邏輯塊號，i

linux核心目錄分析

kernel目錄分析 一 分析源目錄下資料夾： 1.arch arch是architecture的縮寫，意思是架構。arch目錄下是好多個不同架構的CPU的子目錄，譬如arm這種cpu的所有檔案都在arch/arm目錄下，X86的CPU的所有

塊IO層（Linux核心原始碼分析）

背景 本篇部落格重點分析塊IO層，試圖瞭解在linux原始碼中是如何實現塊IO的。 基本知識 塊裝置與字元裝置 塊裝置與字元裝置都是物理外設。簡單來說，塊裝置與字元裝置的最大區別在於塊裝置都隨機對資料片段進行讀寫的，而字元裝置都以順序對資料片段進

arm學習之linux核心移植分析

  linux核心可從 Kernel.org 上獲得，其中偶數版本為穩定版本。 linux核心程式碼結構：     kernel/   核心管理的核心程式碼(系統相關程式碼在arch/*/kernel中)     arch/     體系結構相關程式碼,每個目彔程式碼一個

ARMv8 Linux核心原始碼分析：__flush_dcache_all()

1.1   /* *  Flush the wholeD-cache.  * Corrupted registers: x0-x7, x9-x11  */ ENTRY(__flush_dcache_all) //保證之前的訪存指令的順序     dsb sy      

記憶體管理（Linux核心原始碼分析）

背景 本篇部落格試圖通過linux核心原始碼分析linux的記憶體管理機制，並且對比核心提供的幾個分配記憶體的介面函式。然後聊下slab層的用法以及介面函式。 核心分配記憶體與使用者態分配記憶體 核心分配記憶體與使用者態分配記憶體顯然是不同的，核心不可

Linux核心原始碼分析--記憶體管理（二、函式實現技巧）

        仔細的分析了一下各個記憶體管理函式的實現，發現裡面涉及到了幾個技巧，如果知道了這幾個技巧，那麼閱讀記憶體管理原始碼將會事半功倍（主要是這幾個技巧在幾個函式中都出現過），當然也會選擇性的分析幾個比較重要的函式實現； 函式實現技巧         1、向上取整