Linux到底在何时panic
来源:互联网 发布:农村广电网络宽带 编辑:程序博客网 时间:2024/04/28 18:52
对于纯程序员来讲,特别是习惯于使用“库”的程序员来讲,他们总是认为肯定“底层”会捕获错误的,唯一的例外是c语言的malloc/free,用malloc/free来阐述panic机制应该再好不过了。malloc的内存当然要在不使用的时候free掉,然而即使你free了,这个内存对于操作系统来讲可能还是可用的,也就是说在页表中还是具有映射的,只是对于程序来讲,它已经不能再使用了。操作系统和程序并不站在一个层次考虑问题,操作系统比程序更底层,由于设计原因它只提供机制,因此它并不知道内存的实际用处,它对内存访问的约束是很小的,只要求页表中有映射即可,然而程序却对内存的使用有着更多的依赖,且这种依赖并不为内核所知,因此应用程序必须自己管理内存的使用。
对于panic的机制而言,由于它是内核的机制,因此也不能指望更底层的机制发现错误并调用它,而是需要自己调用。更底层的无非就是cpu硬件了,对于cpu而言,它的约束更少,它只是顺序得从物理内存中取得一个指令,然后执行之,仅此而已,至于是什么指令它不管。如果它取出的不是指令,cpu会触发一个异常,异常号为6,在操作系统初始化的时候需要设置这个异常处理程序:
set_trap_gate(6,&invalid_op);
这也许是cpu提供的最后的措施了,你完全可以在6号异常的处理函数中什么都不做。接下来cpu只管不断取出指令不断执行。试想一种情况,如果panic函数所在的内存被清零了,会发生什么?panic还会调用吗?注意,cpu的hlt指令并不能使cpu停止运行,若想其停止运行,必须借助外部的电源电路。而且也不要觉得在操作系统中输入reboot之后系统就会重启,因此就认为cpu有所谓的复位功能,其实cpu并没有复位,而仅仅跳转到了计算机刚启动时实模式的某一个地址中去了。
现在先在/proc/kallsyms中找到panic的地址:
c126c156 T panic
我们根据linux的内存映射模型,知道panic的物理地址是0x126c156,于是我们执行下面的操作:
dd if=/dev/zero of=/dev/mem bs=1 count=128 seek=0x126c156
然后写一个module,在init函数中直接调用panic,这样我们在insmod的时候,内核会报段错误,因此即使你设置了kernel.panic=1,也不要指望系统在panic后1秒后重启,因为系统根本就不会panic了,panic已经没个球了。
正如应用程序员需要严守malloc/free一样,内核的编写者必须明确何时应该panic。
- linux到底在何时panic
- Linux到底在何时panic
- Linux到底在何时panic
- linux到底在何时panic
- Linux到底何时panic
- Linux panic
- Nologging到底何时才能生效?
- Nologging到底何时才能生效?
- Nologging到底何时才能生效?
- Nologging到底何时才能生效
- Linux到底“错”在哪?
- linux-panic.c
- [转]Linux kernel panic
- Linux kernel panic解决方法
- linux panic 和 bug_on
- linux kernel panic
- Linux kernel panic解决方法
- Linux kernel panic解决方法
- c#"分析 EntityName 时出错"的解决方案
- valgrind内存检查工具
- Android深入浅出之Audio第三部分Audio Policy[1]
- 小心!别让孩子“潮”过头
- 什么是积分墙?
- Linux到底在何时panic
- HDU 1024 Max Sum Plus Plus
- Android Intent和Intent Filter介绍
- Oracle 对象统计信息
- JDK自带的实用工具native2ascii.exe
- 21. 面向对象的LotusScript(四)之MonthConverter
- 【网摘】BCGControlBar入门使用手册
- ALSA SOC Android
- 可重入与线程安全