linux内核中的Oops

2022-04-11 14:49:42 来源：

导读大家好，我是本期栏目编辑小友，现在为大家讲解linux内核中的Oops问题。什么是哎呀？从语言学的角度来看，哎呀应该是一个拟声词。发生一点

大家好，我是本期栏目编辑小友，现在为大家讲解linux内核中的Oops问题。

什么是哎呀？从语言学的角度来看，哎呀应该是一个拟声词。发生一点小意外或者尴尬的事情，可以说‘哎呀’，翻译成中文就叫‘哎哟’。哦，对不起，对不起，我真的不是故意打破你的杯子的。看，这就是“哎呀”的意思。

Linux内核开发中的Oops是什么？其实和上面的解释没有本质区别，只是主角变成了Linux。当一些致命的问题出现时，我们的Linux内核会抱歉地对我们说：“哎呀，对不起，我搞砸了”。当内核死机时，Linux内核会打印出Oops信息，并向我们显示当前的寄存器状态、堆栈内容和完整的Call跟踪，可以帮助我们定位错误。

接下来，我们来看一个例子。为了突出这篇文章的主角——哎呀，这个例子唯一的功能就是创建一个空指针引用错误。

查看sourceprint？01 #包含Linux/kernel . h 02 #包含Linux/module . h 03 04 STATic int _ _ init hello _ init(void)05 { 06 int * p=0；07 08 * p=1；09返回0；10 } 11 12 STATic void _ _ exit hello _ exit(void)13 { 14 return；15 } 16 17 module _ init(hello _ init)；18模块_退出(hello _ exit)；19 20 MODULE _ LICENSE(' GPL ')；显然，错的地方是8号线。

接下来，我们编译这个模块并用insmod将其插入内核空间。正如我们所料，哎呀出现了。

[ 100.243737] BUG:无法在(空)处处理内核空指针取消引用

[100.244985]IP:[f82d 2005]hello _ init0x 5/0x 11[hello]

[ 100.262266] *pde=0000000

[100.288395]Oop : 0002[# 1]SMP

[ 100.305468]最后一个sysfs文件：/sys/devices/virtual/sound/TiMer/uevent

[ 100.325955]在： hello()中链接的模块vmblock vsock vmmemctl vmh GFS acpippp snd _ ens 1371 game port snd _ ac97 _ codec ac97 _ bus snd _ PCM _ OSS snd _ mixer _ OSS snd _ PCM snd _ seq _ dummy snd _ seq _ OSS snd _ seq _ mi

di snd_rawmidi snd_seq_midi_event snd_seq snd_TImer snd_seq_device ppdev psmouse serio_raw fbcon tileblit font bitblit softcursor snd parport_pc soundcore snd_page_alloc vmci i2c_piix4 vga16fb vgastate intel_agp agpgart shpchp lp parport floppy pcnet32 mii mptspi mptscsih mptbase scsi_transport_spi vmxnet

[ 100.472178] [ 100.494931] Pid: 1586, comm: insmod Not tainted (2.6.32-21-generic #32-Ubuntu) VMware Virtual Platform

[ 100.540018] EIP: 0060:[<f82d2005>] EFLAGS: 00010246 CPU: 0

[ 100.562844] EIP is at hello_init+0x5/0x11 [hello]

[ 100.584351] EAX: 00000000 EBX: fffffffc ECX: f82cf040 EDX: 00000001

[ 100.609358] ESI: f82cf040 EDI: 00000000 EBP: f1b9ff5c ESP: f1b9ff5c

[ 100.631467] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068

[ 100.657664] Process insmod (pid: 1586, ti=f1b9e000 task=f137b340 task.ti=f1b9e000)

[ 100.706083] Stack:

[ 100.731783] f1b9ff88 c0101131 f82cf040 c076d240 fffffffc f82cf040 0072cff4 f82d2000

[ 100.759324] <0> fffffffc f82cf040 0072cff4 f1b9ffac c0182340 f19638f8 f137b340 f19638c0

[ 100.811396] <0> 00000004 09cc9018 09cc9018 00020000 f1b9e000 c01033ec 09cc9018 00015324

[ 100.891922] Call Trace:

[ 100.916257] [<c0101131>] ? do_one_initcall+0x31/0x190

[ 100.943670] [<f82d2000>] ? hello_init+0x0/0x11 [hello]

[ 100.970905] [<c0182340>] ? sys_init_module+0xb0/0x210

[ 100.995542] [<c01033ec>] ? syscall_call+0x7/0xb

[ 101.024087] Code: <c7> 05 00 00 00 00 01 00 00 00 5d c3 00 00 00 00 00 00 00 00 00 00

[ 101.079592] EIP: [<f82d2005>] hello_init+0x5/0x11 [hello] SS:ESP 0068:f1b9ff5c

[ 101.134682] CR2: 0000000000000000

[ 101.158929] ---[ end trace e294b69a66d752cb ]---

Oops首先描述了这是一个什么样的bug，然后指出了发生bug的位置，即“IP: [<f82d2005>] hello_init+0x5/0x11 [hello]”。

在这里，我们需要用到一个辅助工具objdump来帮助分析问题。objdump可以用来反汇编，命令格式如下：

objdump -S hello.o

下面是hello.o反汇编的结果，而且是和C代码混排的，非常的直观。

view sourceprint? 01 hello.o: file format elf32-i386 02 03 04 Disassembly of section .init.text: 05 06 00000000 <init_module>: 07 #include <linux/kernel.h> 08 #include <linux/module.h> 09 10 static int __init hello_init(void) 11 { 12 0: 55 push %ebp 13 int *p = 0; 14 15 *p = 1; 16 17 return 0; 18 } 19 1: 31 c0 xor %eax,%eax 20 #include <linux/kernel.h> 21 #include <linux/module.h> 22 23 static int __init hello_init(void) 24 { 25 3: 89 e5 mov %esp,%ebp 26 int *p = 0; 27 28 *p = 1; 29 5: c7 05 00 00 00 00 01 movl $0x1,0x0 30 c: 00 00 00 31 32 return 0; 33 } 34 f: 5d pop %ebp 35 10: c3 ret 36 37 Disassembly of section .exit.text: 38 39 00000000 <cleanup_module>: 40 41 static void __exit hello_exit(void) 42 { 43 0: 55 push %ebp 44 1: 89 e5 mov %esp,%ebp 45 3: e8 fc ff ff ff call 4 <cleanup_module+0x4> 46 return; 47 } 48 8: 5d pop %ebp 49 9: c3 ret

对照Oops的提示，我们可以很清楚的看到，出错的位置hello_init+0x5的汇编代码是：

view sourceprint? 1 5:c7 05 00 00 00 00 01 movl $0x1,0x0

这句代码的作用是把数值1存入0这个地址，这个操作当然是非法的。

我们还能看到它对应的c代码是：

view sourceprint? 1 *p = 1;

Bingo！在Oops的帮助下我们很快就解决了问题。

我们再回过头来检查一下上面的Oops，看看Linux内核还有没有给我们留下其他的有用信息。

Oops: 0002 [#1]

这里面，0002表示Oops的错误代码（写错误，发生在内核空间），#1表示这个错误发生一次。

Oops的错误代码根据错误的原因会有不同的定义，本文中的例子可以参考下面的定义（如果发现自己遇到的Oops和下面无法对应的话，最好去内核代码里查找）：

* error_code: * bit 0 == 0 means no page found, 1 means protection fault * bit 1 == 0 means read, 1 means write * bit 2 == 0 means kernel, 1 means user-mode * bit 3 == 0 means data, 1 means instruction

有时候，Oops还会打印出Tainted信息。这个信息用来指出内核是因何种原因被tainted（直译为“玷污”）。具体的定义如下：

1: 'G' if all modules loaded have a GPL or compatible license, 'P' if any proprietary module has been loaded. Modules without a MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by insmod as GPL compatible are assumed to be proprietary. 2: 'F' if any module was force loaded by "insmod -f", ' ' if all modules were loaded normally. 3: 'S' if the oops occurred on an SMP kernel running on hardware that hasn't been certified as safe to run multiprocessor. Currently this occurs only on various Athlons that are not SMP capable. 4: 'R' if a module was force unloaded by "rmmod -f", ' ' if all modules were unloaded normally. 5: 'M' if any processor has reported a Machine Check Exception, ' ' if no Machine Check Exceptions have occurred. 6: 'B' if a page-release function has found a bad page reference or some unexpected page flags. 7: 'U' if a user or user application specifically requested that the Tainted flag be set, ' ' otherwise. 8: 'D' if the kernel has died recently, i.e. there was an OOPS or BUG. 9: 'A' if the ACPI table has been overridden. 10: 'W' if a warning has previously been issued by the kernel. (Though some warnings may set more specific taint flags.) 11: 'C' if a staging driver has been loaded. 12: 'I' if the kernel is working around a severe bug in the platform firmware (BIOS or similar).

基本上，这个Tainted信息是留给内核开发者看的。用户在使用Linux的过程中如果遇到Oops，可以把Oops的内容发送给内核开发者去debug，内核开发者根据这个Tainted信息大概可以判断出kernel panic时内核运行的环境。如果我们只是debug自己的驱动，这个信息就没什么意义了。

本文的这个例子非常简单，Oops发生以后没有造成宕机，这样我们就可以从dmesg中查看到完整的信息。但更多的情况是Oops发生的同时系统也会宕机，此时这些出错信息是来不及存入文件中的，关掉电源后就无法再看到了。我们只能通过其他的方式来记录：手抄或者拍照。

还有更坏的情况，如果Oops信息过多的话，一页屏幕显示不全，我们怎么来查看完整的内容呢？第一种方法，在grub里用vga参数指定更高的分辨率以使屏幕可以显示更多的内容。很明显，这个方法其实解决不了太多的问题；第二种方法，使用两台机器，把调试机的Oops信息通过串口打印到宿主机的屏幕上。但现在大部分的笔记本电脑是没有串口的，这个解决方法也有很大的局限性；第三种方法，使用内核转储工具kdump把发生Oops时的内存和CPU寄存器的内容dump到一个文件里，之后我们再用gdb来分析问题。

开发内核驱动的过程中可能遇到的问题是千奇百怪的，调试的方法也是多种多样，Oops是Linux内核给我们的提示，我们要用好它。

标签：