linux panic 问题定位

1     概述

详细描述出现kernel panic时的处理过程。

 

2     定位方法

2.1   调用栈

最直接、简单的方法,查看panic时的调用栈,根据打印的出错函数及文件行数,找到panic的位置,再详细处理。

2.2   出错地址

有时候会出现错误的调用栈,此时必须查看出错的指令地址,对于x86架构来说,就是EIP,同时关注调用栈的地址。在调用栈错误时,可以手工将地址转换成出错函数及行数,以下分两个部分介绍:

2.2.1  内核模块

大部分kernel panic都是由于可加载卸载的内核模块导致,此时可以通过如下步骤将地址翻译成具体代码位置。

1.     获取内核模块基地址

查看/proc/modules,找到关注的内核模块的基地址,如下是一个示例

root@miner:~#cat /proc/modules | grep mm

mm           643877 0 - Live 0xd27cf000 (O)

mm_if       1526      1mm, Live 0xd27b8000 (O)

绝大部分情况下,系统在重启后,模块的基地址不会改变。如上图所示,mm模块的地址空间从基地址0xd27cf000开始,大小为643877,如果某个地址落在这个区间,则确定为此模块的地址。

2.     计算地址偏移

将出错的内核地址减去模块基地址,即得到偏移地址。

3.     生成模块可调试文件

确保编译内核时EXTRA_CFLAGS参数添加-g,如此编译后会生成内核模块对应的.o文件(假设为hello.o),使用编译工具链ld(交叉编译时需要使用交叉编译工具链),命令如下:

 ld -r -d -o hello.ko.debug hello.o

4.     gdb调试

gdbhello.ko.debug

假设偏移地址为0xa7d0,则info line*0xa7d0便得到panic时的位置信息。

2.2.2  内核

如果出错地址为内核,则不需要计算偏移地址,直接使用出错地址即可。,使用gdb 调试vmlinux,注意不是vmlinuz,方法基本与内核模块类似


 

3     panic 实例

3.1    代码段卸载

现象

insmod 模块报“operation not permitted”,很快出现panic 信息。此问题为与客户联调时现场出现。

定位

此问题最终原因是模块初始化时接口返回值混乱导致,实际上此模块已经成功插入到内核,但是因为返回值混乱,导致判断是插入模块失败,因此当前内核模块退出,此内核模块的代码段卸载,但此内核模块注册到内核报文处理过程没有被正确卸载,故在报文收发时因为没有可用的代码段导致panic。

 

3.2    死锁

现象

设备在报文有流量的情况下下发配置到内核,会小概率性的出现panic,panic时串口显示“rcu_preempt self-detected stall on CPU”

定位

此问题最终原因是内核死锁。有两个过程需要同步,一个是报文收发软中断,另一个是命令下发过程(进程上下文),代码中使用spin_lock 同步。

在命令下发过程中,锁已经获取,但恰好此时有一个软中断到来,打断了命令下发过程,而且在软中断过程中需要获取相同的锁,此锁已经被命令下属过程占住,因此导致死锁。解决方法很简单,在命令下发过程中禁止软中断,即使用spin_lock_bh 同步。

 

3.3    代码段替换

现象

短时间内,内核模块卸载再加载后,会随机小概率的出现panic

定位

内核模块会在流结构中存储若干内容,包括分配的结点指针等。当内核模块卸载之后,这条流一直存在没有结束;当内核模块两次加载后,这条流又被处理,使用了前一次无效的结点指针,导致panic。

此问题通过“模块引用”计数方案解决,当内核模块卸载再加载后,之前已经处理过的流直接bypass。

 

3.4    使用释放的内存

现象

网口down再up之后,小概率的出现panic,出错信息如下:

<1>[592005.836736]BUG: unable to handle kernel NULL pointer dereference at 00000001
<1>[592005.845688]IP: [<f89a6075>] 0xf89a6074
<4>[592005.846675]*pde = 00000000
<4>[592005.846675]Oops: 0000 [#1]
<4>[592005.846675]Modules linked in: algapi [last unloaded: maxnet_dpi_if]
<4>[592005.846675]
<4>[592005.846675]Pid: 0, comm: swapper Tainted: G          O 3.3.8 #38 HOLL Technologies        /       
<4>[592005.846675]EIP: 0060:[<f89a6075>] EFLAGS: 00010246 CPU: 0
<4>[592005.846675]EIP is at 0xf89a6075
<4>[592005.846675]EAX: c19b6c08 EBX: 00000000 ECX: 00000000 EDX: f59be000
<4>[592005.846675]ESI: f59be000 EDI: 00000001 EBP: c19b6c10 ESP: f600bbac
<4>[592005.846675]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
<0>[592005.846675]Process swapper (pid: 0, ti=f600a000 task=c14264c0 task.ti=c141e000)
<0>[592005.846675]Stack:
<4>[592005.846675]  00000000 fffffffe 00000000 c19b7600 c12b775dc1a9fb30 b554c74e 00000869
<4>[592005.846675]  c1a9fc30 c1a9f8c0 c1a9f800 00000000 0386df19c1a9f800 00000001 c1a9fb30
<4>[592005.846675]  c1a9fa30 b90e8051 00000869 c19b7600 c1a9fb30c1a9fa30 c1a9f910 c1a9f800
<0>[592005.846675]Call Trace:
<4>[592005.846675]  [<c12b775d>] ? htb_dequeue+0x3ad/0x7a0
<4>[592005.846675]  [<c12b0635>] ? __qdisc_run+0x75/0xf0


 

定位

粗看发现htb_dequeue函数,后来仔细查看是在我们自己的内核模块sch_per,是通过EIP地址转换得到,不清楚此版本的linux kernel显示调用栈为什么不完整。

具体原因是在网口down时,会释放当前所有的IP结点,但是其活跃链表的链表头没有初始化,仍然指向了已经释放的IP结点,导致网口再次up时,出现panic。

 

3. 现象

<1>[3872.496538] BUG: unable to handle kernel NULL pointer dereference at   (null)
<1>[3872.504815] IP: [<  (null)>]   (null)
<4>[3872.506445] *pde = 00000000
<4>[3872.506445] Oops: 0000 [#1]
<4>[3872.506445] Modules linked in: maxnet_dpi(O) sch_per(O)
<4>[3872.506445]
<4>[3872.506445] Pid: 0, comm: swapper Tainted: G           O 3.3.8 #44 MICRO-STAR INTERNATIONALCO., LTD MS-9641/MS-9641
<4>[3872.506445] EIP: 0060:[<00000000>] EFLAGS: 00010286 CPU: 0
<4>[3872.506445] EIP is at 0x0
<4>[3872.506445] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: c1a3d96d
<4>[3872.506445] ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: f680bce8
<4>[3872.506445]  DS: 007b ES: 007b FS: 0000GS: 0000 SS: 0068
<0>[3872.506445] Process swapper (pid: 0, ti=f680a000 task=c14264c0task.ti=c141e000)
<0>[3872.506445] Stack:
<4>[3872.506445]  00000000 00000000 00000000f680bd08 f89237d0 f680bd40 f88fb0a2 c1a3d840
<4>[3872.506445]  00000000 00000000 0000000000000000 00000000 00000000 00000000 00000000
<4>[3872.506445]  00000000 00000000 0000000000000000 00000006 00000000 f88fb41c c12c9500
<0>[3872.506445] Call Trace:
<4>[3872.506445]  [<f89237d0>] ?miner_qos_fini+0x240/0x600 [maxnet_dpi]


某一台设备,经常性的panic(每天平均一次以上),但EIP记录为0,无法获得panic时的地址,通过翻译调用栈地址,仅能得到在内核模块的forward函数和local_in函数位置,详细的panic位置无法获取。

 

粗略查看,panic有两种情况,一种是在0xf89237d0,另一种是在0xf89237bb,目前已知maxnet-dpi.ko 的基地址为0xf8919000,这两种情况如下:

(1) 0xf89237d0

此地址(偏移地址为0xa7d0)定位到函数 app_local_in 的第一行,反汇编后查看,发现指令如下:

0000a7d0 <app_local_in>:

#ifndef MAXNET_CHINA_TELECOM

static int app_local_in(unsigned char*layer2_data, maxnet_tupleinfo_t *tuple, void *data)

{

   a7d0:       57                      push   %edi

仅仅一个入栈动作(push %edi)导致panic,如果其地址可信,怀疑可能是硬件问题。

 

(2) 0xf89237bb

此地址定位到maxnet_dpi_proc函数的最后一行,即maxnet_dpi_forward调用处

 

此问题仅在一台设备上出现,且此设备为很多年前的、不发货仅供测试的设备,也可能是硬件问题

此问题待定,目前尚未解决!!!!!!!


l  现象2

程序在某台网关设备上频繁重启,相关日志如下:

CPU 0 Unable to handle kernel pagingrequest at virtual address 587d7a98, epc == c224ca68, ra == c224cc0c
Oops[#1]:
Cpu 0
$ 0  : 00000000 00000031 ffff0000 00000000
$ 4  : 00000001 00000006 00000000 00000000
$ 8  : 00007740 8bd8791a 00000010 64725049
$12  : 00000000 00000000 00000000 00000000
$16  : 7376694f 43394e4f 64725049 587d7a98
$20  : c228ed60 c2290000 8b9e8100 00000004
$24  : 00000010 c128c3cc                 
$28  : 8d7d4000 8d7d7a38 8d7d7c28 c224cc0c
Hi   : 033e3b62
Lo   : f4806fde
epc  : c224ca68 maxnet_dpi_proc+0xa8/0x374 [m01_b01]
   Tainted: P           O
ra   : c224cc0c maxnet_dpi_proc+0x24c/0x374 [m01_b01]
Status: 10009903    KERNEL EXL IE
Cause : 0000000c
BadVA : 587d7a98
PrId : 0002a080 (Broadcom BMIPS4350)
Call Trace:
[<c224ca68>]maxnet_dpi_proc+0xa8/0x374 [m01_b01]
[<c173420c>]ips_check+0xc0/0x14c [dpi]



查看出错代码位置的反汇编,发现对应的代码段如下:

*layer7_id= 0;
layer3_data =IP_HEADER_FROM_MAC(layer2data);
eh = (struct ethheader*) layer2data;
if ( IP_PROTO_UDP ==tupleinfo->proto ) {
/*4. we check the hostnameby DHCP for osinfo detection */
if ( MAXNET_DPI_ENGINE_ON== g_dpi_engine_conf.osinfo_engine_status ){
if((!tupleinfo->direct)&&
68 ==ntohs(tupleinfo->sport) &&
67 ==ntohs(tupleinfo->dport)){
memcpy(mac_address,eh->h_source, 6);
dpi_osinfo_refresh_hostname(layer3_data,tupleinfo->sipv4, mac_address);
}
}
}
*layer7_id= 0;



出错的指令地址对应红色代码,但上方不远处有相同的代码,故认为是DHCP处理函数(dpi_osinfo_refresh_hostname)导致,详细查看代码,发现其内部的子函数在memcpy 时没有注意长度,会导致栈数组越界。

栈越界时,会将很多信息破坏,包括调用栈、返回指针,所以之前看到的panic,连EIP都是错的,以后如果看到调用栈损坏、EIP非法,就可以考虑是否为栈越界。


  • 1
    点赞
  • 30
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
好的,下面是一个简单的 Linux kernel panic 堆栈信息解析示例: ``` Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [<c0102a9e>] (unwind_backtrace+0x0/0xe8) from [<c042f8f6>] (panic+0x64/0x13c) [<c042f8f6>] (panic+0x64/0x13c) from [<c042d7c2>] (do_exit+0x5fe/0x602) [<c042d7c2>] (do_exit+0x5fe/0x602) from [<c0101e80>] (die+0x20c/0x214) [<c0101e80>] (die+0x20c/0x214) from [<c0113a98>] (__do_kernel_fault.part.3+0x5c/0x84) [<c0113a98>] (__do_kernel_fault.part.3+0x5c/0x84) from [<c0113b88>] (do_page_fault+0x2a0/0x2b8) [<c0113b88>] (do_page_fault+0x2a0/0x2b8) from [<c0100e6e>] (do_DataAbort+0x34/0x98) [<c0100e6e>] (do_DataAbort+0x34/0x98) from [<c0102d24>] (__dabt_svc+0x44/0x60) ---[ end trace 5a7926b607e5b2d5 ]--- ``` 这个堆栈信息表示系统发生了一个 kernel panic,导致系统无法正常运行。下面是对每一行的解析: - 第一行是 kernel panic 的描述信息,告诉我们出现了什么问题。 - 第二行中的 `<c0102a9e>` 表示函数 `unwind_backtrace` 在代码中的位置,`0x0/0xe8` 表示函数内部的偏移量。这个函数是用来跟踪函数调用栈的,可以帮助我们定位问题发生的位置。 - 第三行中的 `<c042f8f6>` 表示函数 `panic` 在代码中的位置,`0x64/0x13c` 表示函数内部的偏移量。这个函数会导致系统进入 panic 模式,因此我们需要关注它。 - 第四行中的 `<c042d7c2>` 表示函数 `do_exit` 在代码中的位置,`0x5fe/0x602` 表示函数内部的偏移量。这个函数是用来退出进程的,可能与问题有关。 - 第五行中的 `<c0101e80>` 表示函数 `die` 在代码中的位置,`0x20c/0x214` 表示函数内部的偏移量。这个函数是用来输出错误信息和导致系统进入 panic 模式的,因此我们需要关注它。 - 第六行中的 `<c0113a98>` 表示函数 `__do_kernel_fault.part.3` 在代码中的位置,`0x5c/0x84` 表示函数内部的偏移量。这个函数是用来处理页面故障的,可能与问题有关。 - 第七行中的 `<c0113b88>` 表示函数 `do_page_fault` 在代码中的位置,`0x2a0/0x2b8` 表示函数内部的偏移量。这个函数也是用来处理页面故障的,可能与问题有关。 - 第八行中的 `<c0100e6e>` 表示函数 `do_DataAbort` 在代码中的位置,`0x34/0x98` 表示函数内部的偏移量。这个函数是用来处理数据异常的,也可能与问题有关。 - 最后一行表示跟踪结束的信息,可以忽略。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值