mmap_sem信号量死锁故障分析

1 故障现象

     该故障出现时，系统提供的调试shell，命令行都不能执行，只有busybox shell （bshell）和魔键(sysrq)可以用。在串口下启动进程就被挂住，进程都处于D状态。

2 故障定位分析

        该故障出现时，只有bshell跟魔键信息可以用，自然而然的就敲了魔键，把内核的调用链打印出来，可是，魔键打印的内核调用链信息很多，很难从调用链的信息中找到出问题的任务。面对收集到的信息，却没有定位的思路，那只能从魔键的函数调用链开始分析，业务进程（app）中的子线程，很多都有类似的函数调用关系，调用关系如下所示：

schedule

__down_read

do_page_fault 

       根据 内核调用链提示的信息，走查代码，发现缺页异常时，获取mmap_sem信号量的时候，没有获取成功，然后主动调用schedule放弃cpu。也就是说app中的多数任务在缺页异常时，获取mmap_sem信号量失败，导致大多数任务都被阻塞在mmap_sem信号量上。从代码上看是请求mmap_sem信号量失败，但是什么情景下会出现这种现象，为什么会出现这种现象暂时不清楚。跟同事讨论，觉得应该是个信号量死锁问题。

      如果是信号量死锁问题，那么当前系统必须满足三个条件:

        1)高优先级任务抢占中优先级任务，并申请mmap_semp信号量

         2）存在中优先级的死循环任务