内核bug的原因可能有:
- 错误代码
- 同步时发生的错误,例如共享变量锁定不当
- 错误的管理硬件
- ……
内核bug发作的症状可能有:
- 降低所有程序的运行性能
- 毁坏数据
- 使得系统处于死锁状态
- ……
内核开发比起用户开发要多考虑一些独特的问题,比如:
- 定时限制
- 竞争条件
- ……
原因是允许多个线程在内核中同时运行。
printk()
和printf()
在使用上最主要的区别就是前者可以指定一个日志级别。内核通过这个级别来判断是否在终端上打印消息。内核把级别比某个特定值低的所有消息显示在终端上。
如果没有指定一个记录等级,函数会选用默认的DEFAULT_MASSAGE_LOGLEVEL
。
内核会把这些记录等级转化,n指等级,从0-7,对应表中从上到下,数字越小越重要。
0 KERN_EMERG 最重要
7 KERN_DEBUG 最不重要
调试信息, 有两种赋予记录等级的方法:
printk的输出日志级别如下:
等级 | 描述 |
---|---|
KERN_ EMERG | 一个紧急情况 |
KERN_ ALERT | 一个需要立即被注意到的错误 |
KERN_ CRIT | 一个临界情况 |
KERN_ ERR | 一个错误 |
KERN_ WARNING | 一个警告 |
KERN_ NOTICE | 一个普通的, 不过也有可能需要注意的情况 |
KERN_ INFO | 一条非正式的消息 |
KERN_ DEBUG | 一条调试信息--一般是冗余信息 |
oops是内核告知用户有不幸发生的最常用的方式。
内核很难自我修复,也不能将自己杀死,只能发布oops,过程包括:
- 向终端上输出错误消息
- 输出寄存器中保存的信息
- 输出可供跟踪的回溯线索
通常发送完oops之后,内核会处于一种不稳定状态。
关于oops发生的时机:
内和调试配置项:
引发bug并打印信息:
系统请求键
oops中包含的重要信息:寄存器上下文和回溯线索
回溯线索中的地址需要转化成有意义的符号名称
——需要调用ksymoops命令。
并且还必须提供编译内核时产生的System.map。如果用的是模块,还需要一些模块信息。
kysmoop saved_oops.txt
现在的版本中不需要使用sysmoops这个工具,因为可能会发生很多问题,新版本中引入了kallsyms疼,可以通过定义CONFIG_KALLSYMS配置选项启用。
可以使用标准的GNU调试器对正在运行的内核进行查看。
针对内核启动调试器的方法与针对进程的方法大致相同:
gdb vmlinux /proc/kcore
vmlinx:未经压缩的内核映像,区别于zImage或bImage,它存放于源代码树的根目录上。
/proc/kcore作为一个参数选项,是作为core文件来用的,通过它能够访问到内核驻留的高端内存。只有超级用户才能读取此文件的数据
可以使用gdb的所有命令来获取信息。例如:
打印一个变量的值:
p global_variable
反汇编一个函数:
disassemble function
-g参数还可以提供更多的信息。
局限性:
是一个补丁 ,可以让我们在远程主机上通过串口利用gdb的所有功能对内核进行调试。
需要两台计算机:仪态运行带有kgdb补丁的内核,第二胎通过串行线使用gdb对第一台进行调试。
通过kgdb,gdb的所有功能都能使用:
- 读取和修改变量值
- 设置断点
- 设置关注变量
- 单步执行
一般情况下,加入特性时,只要保留原有的算法而把新算法加入到其他位置上,基本就能保证安全。
可以把用户id(UID)作为选择条件来实现这种功能:
通过某种选择条件,安排到底执行哪种算法。
例如:
if (current-> uid !=7777) {
/* 老算法…… */
} else {
/* 新算法…… */
}
即,除了uid=7777的用户以外,其他所有的用户都是用的老算法,所以这个7777用户可以专门用来测试新算法。
如果代码与进程无关,或者希望有一个针对所有情况都能使用的机制来控制某个特性,可以使用条件变量。
这种方式比使用UID更简单,只需要创建一个全局变量作为一个条件选择开关:
操控方式:某种接口,或者调试器。
这种方法常用于使用者需要掌握某个特定事件的发生规律的时候。
方法是创建统计量,并提供某种机制访问其统计结果。
当系统的调试信息过多的时候,有两种方式可以防止这类问题发生:
原文:http://www.cnblogs.com/20135302wei/p/5327484.html