linux内核挂死,用crash工具分析Linux内核死锁的一次实战分享

本文简介：

内核死锁问题一般是读写锁(rw_semaphore)和互斥锁(mutex)引起的，本文主要讲如何通过ramdump+crash工具来分析这类死锁问题。

0、背景知识点

ramdump是内存转存机制，我们可以在某个时刻把系统的内存转存到一个文件中，然后与符号信息(vmlinux)一起导入到trace32或crash等内存分析工具中做离线分析。是分析崩溃、死锁、内存泄露等内核疑难问题的重要调试手段。

crash是用于解析ramdump的开源工具(http://people.redhat.com/anderson/)，是命令行式的交互模式，提供诸多功能强大的调试命令，是分析定位内核复杂问题的利器。

死锁是指两个或两个以上的执行流在执行过程中，由于竞争锁资源而造成的一种阻塞的现象。如图：

1、问题描述

在Android7.1系统中跑monkey时出现界面卡死现象：

1)没有任何刷新，所有输入事件无效，包括电源键

2)watchdog没有重启system_server

3)可以连adb，但ps等调试命令卡住

2、初步分析

由于无法直接用adb调试，用长按电源键的方式进入dump模式并导出ramdump文件，之后再用crash工具载入randump文件开始离线分析。

一般卡死时可能是因为核心线程处在UNINTERRUPTIBLE状态，所以先在crash环境下用ps命令查看手机中UNINTERRUPTIBLE状态的线程，参数-u可过滤掉内核线程：

bt命令可查看某个线程的调用栈，我们看一下上面UN状态的最关键的watchdog线程：

从调用栈中可以看到proc_pid_cmdline_read()函数中被阻塞的，对应的代码为：

这里是要获取被某个线程mm的mmap_sem锁，而这个锁又被另外一个线程持有。

3、推导读写锁

要想知道哪个线程持有了这把锁，我们得先用汇编推导出这个锁的具体值。可用dis命令看一下proc_pid_cmdline_read()的汇编代码：

0xffffff99a680aaa0处就是调用down_read()的地方，它的第一个参数x0就是sem锁，如：