用crash分析内核死锁的一次实践

青旅半醒 2022-11-05 00:41 191阅读 0赞

【推荐阅读】

[什么是死锁？][Link 1]

[内核死锁的debug方法][debug]

[**上文**][debug]讲了通过lockdep的方式可以debug出死锁的信息，但是如果出问题的系统没有lockdep的配置，或者没有相关的日志该怎么办？这里分享通过crash工具来动态检测死锁时的问题（除了crash工具外用trace32更方便，可参考https://blog.csdn.net/forever\_2015/article/details/77434580）。

## 用crash初步分析 ##

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

![09b781efdbf8f62e6e3ac8a41dc6d5b6.png][]

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

![851b7917315bb4c76fd86d0e848506f3.png][]

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

static ssize_t proc_pid_cmdline_read(struct file *file, char __user *buf,
             size_t _count, loff_t *pos)
    {
      ......
     tsk = get_proc_task(file_inode(file));
     if (!tsk)
      return -ESRCH;
     mm = get_task_mm(tsk);
     put_task_struct(tsk);
      ......
     down_read(&mm->mmap_sem);
      ......
    }

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

## 推导读写锁 ##

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

![076bc714a0481269f2ca0676f6e741bd.png][]

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

void __sched down_read(struct rw_semaphore *sem)

x0和x28寄存器存放的就是sem的值，那x21自然就是mm\_struct的地址了，因为mm\_struct的mmap\_sem成员的offset就是104（0x68），用whatis命令可以查看结构体的声明，如：

![24ce76acee11500edeeb5cd35388b623.png][]

因此我们只需要知道**x21**或者**x28**就知道mm和mmap\_sem锁的值。

函数调用时被调用函数会在自己的栈帧中保存即将被修改到的寄存器，所以我们可以在down\_read()及它之后的函数调用中找到这两个寄存器：

也就是说下面几个函数中，只要找到用到x21或x28，必然会在它的栈帧中保存这些寄存器。

![81793fbb7d9b8266eb48f6609d9887fd.png][]

先从最底部的down\_read()开始找：

![06f0428cdd8447d04ca9d240998e45e9.png][]

显然它没有用到x21或x28，继续看rwsem\_down\_read\_failed()的汇编代码：

![bb97f59818a83129a03086375e3c9b0a.png][]

在这个函数中找到x21，它保存在rwsem\_down\_read\_failed栈帧的偏移32字节的位置。rwsem\_down\_read\_failed()的sp是0xffffffd6d9e4bcb0

![a37b8b671ef14987f8c1c9ac975de0ae.png][]

sp + 32 =0xffffffd6d9e4bcd0，用rd命令查看地址0xffffffd6d9e4bcd0中存放的x21的值为：

![335a0bf7e975705c39320f8e0e5df3fd.png][]

用struct命令查看这个mm\_struct：

![1ca60cf5996553e813a5e9f09d7cbb3b.png][]

这里的owner是mm\_struct所属线程的task\_struct：

![5a5843ef31f7c533840ade38429017e8.png][]

sem锁的地址为0xffffffd76e349a00+0x68 = **0xffffffd76e349a68**，所以：

![0a287caa4c83042d2543f1a4ddf6b6f8.png][]

分析到这里我们知道watchdog线程是在读取1651线程的proc节点时被阻塞了，原因是这个进程的mm，它的mmap\_sem锁被其他线程给拿住了，那到底是谁持了这把锁呢？

## 持读写锁的线程 ##

带着问题我们继续分析，通过search命令加-t参数从系统中所有的线程的栈空间里查找当前锁：

![f041a469aadd4060482d371c8440bd9b.png][]

一般锁的值都会保存在寄存器中，而寄存器又会在子函数调用过程中保存在栈中。所以只要在栈空间中找到当前锁的值（**0xffffffd76e349a68**），那这个线程很可能就是持锁或者等锁线程

这里搜出的20个线程中19个就是前面提到的等锁线程，剩下的1个很可能就是持锁线程了：

![c3052328adac38f5a435468e09ac3dfa.png][]

查看这个线程的调用栈：

![81860089dd8a3ed70616d18b876667f2.png][]

由于**2124**线程中存放锁的地址是0xffffffd6d396b8b0，这个是在handle\_mm\_fault()的栈帧范围内，因此可以推断持锁的函数应该是在handle\_mm\_fault()之前。

我们先看一下do\_page\_fault函数：

![b0778578573f94898329e014c8bb28eb.png][]

代码中确实是存在持mmap\_sem的地方，并且是读者，因此可以确定是**2124**持有的读写锁阻塞了watchdog在内的19个线程。

接下来我们需要看一下**2124**线程为什么会持锁后迟迟不释放就可以了。

## 死锁 ##

可以看出2124线程是等待fuse的处理结果，而我们知道fuse的请求是sdcard来处理的。

在log中我们看到的确有sdcard相关的UNINTERRUPTIBLE状态的线程**2767**：

![20f136aa4b61c24b7c106c4125ec0a2f.png][]

得2767线程等待的mutex锁是0xffffffd6948f4090，

它的owner的task和pid为：

![5a06ddc699997d5cfc10b66cae0c59ae.png][]

先通过bt命令查找2124的栈范围为0xffffffd6d396b4b0～0xffffffd6d396be70：

![e1456960fd0922a43497034d18d84193.png][]

从栈里面可以找到mutex：

![fb3b65dfa3a07967fdc69be2f7917800.png][]

mutex值在ffffffd6d396bc40这个地址上找到了，它是在\_\_generic\_file\_write\_iter的栈帧里。

![0d25775eef04651b99f49a70237dc780.png][]

那可以肯定是在\_\_generic\_file\_write\_iter之前就持锁了，并且很可能是ext4\_file\_write\_iter中，查看其源码：

![187546071331cdc23112eef3eeb571f7.png][]

这下清楚了，原来2124在等待2767处理fuse请求，而2767又被2124线程持有的mutex锁给锁住了，也就是说两个线程互锁了。

本文只限于介绍如何定位死锁问题，至于如何解决涉及到模块的具体实现，由于篇幅的关系这里就不再赘述了。

![虚线阴影分割线][8f09ceca4eaea166105e56c8402289ab.png]

![5eeadf0f2072c65ed983ed8faa36d0dd.png][]

5T技术资源大放送！包括但不限于：C/C++，Arm, Linux，Android，人工智能，单片机，树莓派，等等。在公众号内回复「peter」，即可免费获取！！

![7f508661f8efba459c2db55dbad69910.gif][] **记得点击****分享****、****赞****和****在看****，给我充点儿电吧**

[Link 1]: http://mp.weixin.qq.com/s?__biz=MzIxMjE1MzU4OA%3D%3D&chksm=8f5d9ef0b82a17e62b063ec1b105292639595782dd241acef15f7251a03760b932cb4c636dbc&idx=1&mid=2648922987&scene=21&sn=e91a8f0adebe94d329ce8aacfcd452e5#wechat_redirect
[debug]: http://mp.weixin.qq.com/s?__biz=MzIxMjE1MzU4OA%3D%3D&chksm=8f5d9ee6b82a17f001133b4a0ffeb182e9d8dafa828730ca1dce75390cda6e3b55c0a8cfad9b&idx=1&mid=2648923005&scene=21&sn=b74bdd7a4949ab3b61b8f6ebf2311c3d#wechat_redirect
[09b781efdbf8f62e6e3ac8a41dc6d5b6.png]: /images/20221023/6eb89fb5da544750a8d5c222e2e799d7.png
[851b7917315bb4c76fd86d0e848506f3.png]: /images/20221023/8e16172f2b13458095ead142b72e6826.png
[076bc714a0481269f2ca0676f6e741bd.png]: /images/20221023/9bd551ee3fcf406d8455fd7c8cd41c60.png
[24ce76acee11500edeeb5cd35388b623.png]: /images/20221023/e6c0c6045ec647dabac4c5c424aebf43.png
[81793fbb7d9b8266eb48f6609d9887fd.png]: /images/20221023/4f64300d17df460eaa3791dfe0525640.png
[06f0428cdd8447d04ca9d240998e45e9.png]: /images/20221023/0e94cdb1e41d438886bf49b7a919c4d1.png
[bb97f59818a83129a03086375e3c9b0a.png]: /images/20221023/c249ddda9336447ca06e45222d54d30a.png
[a37b8b671ef14987f8c1c9ac975de0ae.png]: /images/20221023/5b312067cb654d96a454d9824feae844.png
[335a0bf7e975705c39320f8e0e5df3fd.png]: /images/20221023/e7a9d6de04354a65a47a9257b4c7cb74.png
[1ca60cf5996553e813a5e9f09d7cbb3b.png]: /images/20221023/ad62cf5f7c264bd495c1920ea8f20424.png
[5a5843ef31f7c533840ade38429017e8.png]: /images/20221023/286e6c78ba9e4f9c901c08e233d2cc91.png
[0a287caa4c83042d2543f1a4ddf6b6f8.png]: /images/20221023/00ecde2a3f9f41afa4ef4b188d161055.png
[f041a469aadd4060482d371c8440bd9b.png]: /images/20221023/931b15d362274b2197fe62d78568fd0f.png
[c3052328adac38f5a435468e09ac3dfa.png]: /images/20221023/64dbad3137694280ab71e172951a68e7.png
[81860089dd8a3ed70616d18b876667f2.png]: /images/20221023/690d020d10304efa816b5ac21fa97ce9.png
[b0778578573f94898329e014c8bb28eb.png]: /images/20221023/c317ac4dec554772be35561a36d30670.png
[20f136aa4b61c24b7c106c4125ec0a2f.png]: /images/20221023/d78835a4e52b479fac4e35c0b4d9f27c.png
[5a06ddc699997d5cfc10b66cae0c59ae.png]: /images/20221023/adaf61d10ae64759864622cc8b103aa0.png
[e1456960fd0922a43497034d18d84193.png]: /images/20221023/5708843b9b30478ba47ee6c89a834252.png
[fb3b65dfa3a07967fdc69be2f7917800.png]: /images/20221023/0bf76fd808e942b1ba8cbfd507d17436.png
[0d25775eef04651b99f49a70237dc780.png]: /images/20221023/9ae535ac234d4b12957241f9ed1e32ff.png
[187546071331cdc23112eef3eeb571f7.png]: /images/20221023/c20d61fceba643cb943524afaa47565b.png
[8f09ceca4eaea166105e56c8402289ab.png]: /images/20221023/9aa576ee6d9146a59daf96c2aeb061c4.png
[5eeadf0f2072c65ed983ed8faa36d0dd.png]: /images/20221023/0872d5187bb74b04b5fc641734aca487.png
[7f508661f8efba459c2db55dbad69910.gif]: /images/20221023/053cbf91a30d455aaaf97f46380af5d7.png