发布时间：2015-01-15 15:47:33
kernel 3.10内核源码分析--中断--中断和异常返回流程
一、问题
1、内核调度与中断/异常/系统调用的关系如何？
2、信号处理与中断/异常/系统调用的关系如何？
3、内核抢占与中断/异常/系统调用的关系如何？
这些问题都需要分析清楚中断/异常的返回流程，才能解答。......【阅读全文】
发布时间：2015-06-04 17:16:24
1、基本原理 本文主要涉及ip_append_data中的UFO(UDP Fragment Offload)相关流程，主要由ip_ufo_append_data函数完成相关功能。比较简单。 UFO(UDP Fragment Offload)是硬件网卡提供的一种特性，由内核和驱动配合完成相关功能。其目的是由网卡硬件来完成本来需要软件进行的分段(分片)操作用于提升效率和性能。如大家所知.........【阅读全文】
发布时间：2015-07-29 19:04:27
如何在内核中正确分配和释放page？
?内核中使用内存是再平常不过的事了，但应该如何正确使用呢，尤其是在自己编写驱动时，应该如何正确的分配和释放内存，是一大问题，不理清楚的话，可能导致严重后果，比如：内存泄露、越界、野指针等。......【阅读全文】
发布时间：2015-07-29 18:47:00
本问题是个简单的内核编程问题(spin_lock的用法问题)：spin_lock(task_lock)不能直接在中断上下文中使用，因为这样的锁没有关中断，他可能被中断打断，然后中断上下文中如果再次获取该锁就导致死锁了，除非能确认该锁不会在其它地方使用。
问题很简单，但却很有警示意义。可能有人认为内核代码随便就能写，模仿模仿就行，但实际上，内核编程水很深、坑很多，稍不留神(对相关用法和原理了解不够)就可能会掉坑里，立马掉进去还好，最怕就是给自己埋雷，不知道哪一天会踩到，到时后果就很严重了，所以，对内核的任何改动或新增代码，都需要千万谨慎，多修炼吧！......【阅读全文】
发布时间：2015-07-21 16:00:06
本文讲述一次spinlock死锁故障的定位过程，目的不在于问题本身，而在于展现一个内核bug的分析过程，提供一种分析思路，供大家参考。
一、问题现象
内核出现panic，kdump搜集到了vmcore。vmcore中直接导致panic的log信息为(包含相应CPU上的堆栈)：......【阅读全文】
发布时间：2015-07-16 15:00:58
Crash工具分析某vmcore时，本想看看vmcore中running状态进程的相关状态，但是发现该vmcore中的running状态的进程异常多，而且其堆栈都是在schedule()中，有点不符合常理：......【阅读全文】
发布时间：2015-03-30 07:24:04
kernel 3.10内核源码分析--IO--SCSI错误处理机制
基本原理
SCSI层提供的错误处理机制，主要针对两种IO错误类型(其实也就只有这两种类型)：
1、IO错误(IO Error)。IO错误是底层固件(比如SAS控制器固件或光纤卡固件)主动上报的事件(中断)，表示下发的IO请求(SCSI命令)执行完成，但是出错了。出现的情况较少，典型情况如：磁盘损坏导致IO执行错误。
2、IO超时(IO Timeout)。IO超时是IO请求下发后，在指定时间内(在IO请求下发时会启动相应的定时器，默认为30s，有些特殊的指令设置为60s或10s)没有执行完成(执行完成的标志是有相应的中断事件上报)。那可能的原因就多了，在IO链路上的每个环节出现问题(而又没有相应的事件主动上报时)，都可能出现超时，这种情况相对比较复杂。典型的案例为：光纤卡链路问题(虚断)。
SCSI层提供的错误处理机制基本原理为：
1、在host初始化时启动相应的错误处理内核线程(scsi_eh_x)
2、当出现IO超时(由定时器触发后检测)或IO错误(由软中断触发后检......【阅读全文】
发布时间：2015-03-19 07:21:33
kernel 3.10内核源码分析--BUG_ON流程
一、问题
在dmesg或messages中常见BUG_ON的相关打印，如：
------------[ cut here ]------------
kernel BUG at ...
也常见其它的异常打印，比如page_fault相关的，softlockup相关的，有时候不太好区分它们之间的差别，但区分它们却是否重要，直接关系着对问题本质的判断。
这里简单分析了一下BUG_ON在3.10 kernel代码中的实现。
二、基本原理
BUG_ON通过BUG宏实现。BUG最终是通过执行ud2汇编指令实现。ud2指令看起来有点陌生，大概就是undefine的意思，是一种让CPU产生invalid opcode异常的软件指令，此时会有相应的异常事件上报，内核捕获相应的异常，由预先注册的异常处理接口进行处理：打印相关错误信息，最终根据配置进行kdump或panic或停止当前进程。......【阅读全文】
发布时间：2015-03-11 07:21:35
kernel 3.10内核源码分析--hung task机制
一、相关知识
长期以来，处于D状态(TASK_UNINTERRUPTIBLE状态)的进程都是让人比较烦恼的问题，处于D状态的进程不能接收信号，kill不掉。在一些场景下，常见到进程长期处于D状态，用户对此无能为力，也不知道原因，只能重启恢复。
其实进程长期处于D状态肯定是不正常的，内核中设计D状态的目的是为了让进程等待IO完成，正常情况下IO应该会顺利完成，然后唤醒相应的D状态进程，即使在异常情况下(比如磁盘离或损坏、磁阵链路断开等)，IO处理也是有超时机制的，原理上不会存在永久处于D状态的进程。但是就是因为内核代码流程中可能存在一些bug，或者用户内核模块中的相关机制不合理，可能导致进程长期处于D状态，无法唤醒，类似于死锁状态。
针对这种情况，内核中提供了hung task机制用于检测系统中是否存在处于D状态超过120s(时长可以设置)的进程，如果存在，则打印相关警告和进程堆栈。如果配置了hung_task_panic（proc或内核启动参数），则直接发起panic，结合kdump可以搜集到vmco......【阅读全文】
发布时间：2015-01-23 17:14:02
kernel 3.10内核源码分析--块设备层request plug/unplug机制
一、基本原理
Linux块设备层使用了plug/unplug(蓄流/泄流)的机制来提升IO吞吐量。基本原理为：当IO请求提交时，不知直接提交给底层驱动，而是先将其放入一个队列中(相当于水池)，待一定时机或周期后再将该队列中的请求统一下发。将请求放入队列的过程即plug(蓄流)过程，统一下发请求的过程即为unplug(泄流)过程。每个请求在队列中等待的时间不会太长，通常在ms级别。
如此设计，可以增加IO合并和排序的机会，便于提升磁盘访问效率。......【阅读全文】
发布时间：2015-01-13 10:28:38
Crash工具加载模块符号
一、问题：
?在使用crash工具分析vmcore时，常会遇到内核模块符号不能解析的问题，如：
?crash> struct igbadapter 0xffff81032bef56b8
struct: invalid data structure reference: igbadapter......【阅读全文】
发布时间：2015-01-10 15:26:40
一次kernel panic分析--空指针in handle_IRQ_event
现象：
Unable to handle kernel NULL pointer dereference at 0000000000000039 RIP:
[] handle_IRQ_event+0x44/0xa6
PGD 61df63067 PUD 61ea5a067 PMD 0
Oops: 0000 [1] SMP
last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_max_freq
CPU 8
Modules linked in: ossmod(U) tipc(U) bsp_smbus_ctrl(U) bonding autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc ipv6 xfrm_nalgo crypto_api cpufreq_ondemand acpi_cpufreq freq_table dm_mirror d
m......【阅读全文】
发布时间：2015-01-10 09:51:23
路由和转发基本原理及其它相关
1、问题
主机1--路由器1--网络--路由器2--主机2
这样的组网模型中，从主机1 ping 主机2，网络通信的基本原理是怎样的？......【阅读全文】
发布时间：2015-01-06 13:00:03
一、概念
Linux系统中，应用程序以进程的方式存在，调度也以进程为单位，有关进程的概念就不多说了，参考教科书。
本文主要关注进程状态、偶然会见到的僵尸进程(Z状态)、以及很少见过的X状态进程。
每个进程都有相应的状态，如平常常见的R、S和D状态，也有在出现问题时见到的Z状态，即僵尸状态，还有极少见到的X状态，这也是本文重点分析和关注的。......【阅读全文】
发布时间：2015-01-05 16:50:08
进程调度时，当被选中的next进程不是current进程时，需要进行上下文切换。
进行上下文切换时，有一些问题不太容易理解，比如：
1、进程上下文切换必然发生在内核态吗？
2、上下文切换后原来的进程(prev)如果恢复执行，从什么地方开始执行？
3、上下文切换后，如何切换到新进程执行？新进程从什么地方开始执行？
5、上下文切换时，堆栈如何切换，如果保证不混乱？
6、A进程执行时被打断调度B进程运行，B进程正常执行过程中被打断调度C进程运行，C运行被打断中调度D运行，以此类推，看似一个无限嵌套，如何恢复到A进程运行，不会一层层返回吧？会不会有问题？
7、上下文切换后，如何恢复到新进程的用户态程序继续执行？
上述问题(可能还有其它疑问~)在理解了进程上下文切换的细节后，就都能回答了。......【阅读全文】
