一次由于bugreport 导致内核崩溃的问题分析

 

为了进一步分析出现崩溃时的内核场景，我们在编译打开CONFIG_DEBUG_KERNEL宏（Compile the kernel with debug info），根据上面的内核堆栈和寄存器相关信息，我们根据编译内核的vmlimux文件，打开该功能后，编译出来的目标文件将会携带源码信息，使用./prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/bin/x86_64-linux-android-objdump

命令即可显示出来：

./prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/bin/x86_64-linux-android-objdump -d -l out/android-goldfish-4.4-dev/common/vmlinux > kernelsymbols.txt

 

打开 kernelsymbols.txt，通过查找指针计数器RIP的值sync_print_pt+0xd9/0x1df 查找，

 

/home/clink/zcc/kernel-x86/common/drivers/staging/android/sync_debug.c:157

ffffffff80790ee8:       49 63 c4                movslq %r12d,%rax

/home/clink/zcc/kernel-x86/common/drivers/staging/android/sync_debug.c:160

ffffffff80790eeb:       ba 01 00 00 00          mov    $0x1,%edx

ffffffff80790ef0:       48 89 df                mov    %rbx,%rdi

/home/clink/zcc/kernel-x86/common/drivers/staging/android/sync_debug.c:157

ffffffff80790ef3:       48 6b c0 28             imul   $0x28,%rax,%rax

/home/clink/zcc/kernel-x86/common/drivers/staging/android/sync_debug.c:155 (discriminator 3)

ffffffff80790ef7:       41 ff c4                inc    %r12d

/home/clink/zcc/kernel-x86/common/drivers/staging/android/sync_debug.c:160

ffffffff80790efa:       49 8b 74 05 50          mov    0x50(%r13,%rax,1),%rsi

ffffffff80790eff:       e8 6d fc ff ff          callq  ffffffff80790b71 <sync_print_pt>

ffffffff80790f04:       eb dc                   jmp    ffffffff80790ee2 <sync_debugfs_show+0x192>

spinlock_check():

 

 

跟之前研究的ARM指令集和寄存器差异比较大，里面好像也没有显示函数里面的函数调用情况，不过通过查找sync_print函数，并通过大概位置得出出问题的地方是在sync_print中

 

但是调用seq_printf还好几个地方，最终要通过寄存器加偏移值计算得出对应的代码和变量，通过相关的堆栈信息大概得到调用顺序如下：

sync_debugfs_show  -> sync_print_fence -> sync_print_pt -> seq_printf

 

由于sync_print_fence和sync_print_pt 都是static函数，在编译时都会自动展开，所以在崩溃的堆栈内不能直接看到这两个函数。 

那么现在来看我们已经大概已经知道崩溃在drivers/staging/android/sync_debug.c 的 sync_debugfs_show 函数中，而这个函数是作为sync 文件操作的系统调用接口：

sync_debugfs_open ->  sync_debugfs_show

 

static const struct file_operations sync_debugfs_fops = {

        .open           = sync_debugfs_open,

        .read           = seq_read,

        .llseek         = seq_lseek,

        .release        = single_release,

};

 

 

现在我们结合logcat信息来看看，会发现有这么一段日志：

 

10-10 07:29:27.683  3846  3846 I sh      : type=1400 audit(0.0:1335): avc: denied { read } for name="/" dev="debugfs" ino=1 scontext=u:r:shell:s0 tcontext=u:object_r:debugfs:s0 tclass=dir permissive=1

10-10 07:29:27.683  3846  3846 I sh      : type=1400 audit(0.0:1336): avc: denied { open } for path="/sys/kernel/debug" dev="debugfs" ino=1 scontext=u:r:shell:s0 tcontext=u:object_r:debugfs:s0 tclass=dir permissive=1

10-10 07:29:27.683  3846  3846 I sh      : type=1400 audit(0.0:1337): avc: denied { getattr } for path="/sys/kernel/debug/sync" dev="debugfs" ino=6169 scontext=u:r:shell:s0 tcontext=u:object_r:debugfs:s0 tclass=file permissive=1

10-10 07:29:27.683  3846  3846 I sh      : type=1400 audit(0.0:1338): avc: denied { getattr } for path="/sys/kernel/debug/wakeup_sources" dev="debugfs" ino=6 scontext=u:r:shell:s0 tcontext=u:object_r:debugfs_wakeup_sources:s0 tclass=file permissive=1

 

这个只是selinux的警告，不能说明有问题，但能说明在执行bugreport时，dumpstate是在读取/sys/kernel/debug/sync文件，我们去尝试手动cat /sys/kernel/debug/sync文件,发现一样会崩溃，到这里，问题的原因找到了，是因为这个文件损坏导致，而bugreport在读取这个文件时发生系统崩溃。

 

接下来看看这个文件是因为哪个损坏了，在执行cat 读取sync文件操作时，执行的是sync_debugfs_open ，然后调用sync_debugfs_show 。

经分析，sync文件的内容是通过sync_print_obj 、sync_print_fence 等函数来写入的，通过逐个排除发现是在sync_print_fence导致的文件损坏，

sync_print_fence 是一个打印集合，里面会逐个打印fence指针里面的内容到sync文件中，具体是哪个变量呢？ 由于符号表不准确，我们可以通过逐个排除找到是哪个元素导致的，

通过debug发现，在 sync_print_pt(s, pt, true) 输出内容到sync文件出错了。

for (i = 0; i < fence->num_fences; ++i) {

                struct sync_pt *pt =

                        container_of(fence->cbs[i].sync_pt,

                                     struct sync_pt, base);

 

                sync_print_pt(s, pt, true);

        }

 

 

ctyun_ty1:/ $ cat /sys/kernel/debug/sync
objs:
--------------
fences:
--------------
ctyun_ty1:/ $ 

 

 

目前这个fence pointer的打印暂时不会影响我们问题的分析，为了解决X86环境的bugreport问题，可以不打印这个sync_pt 调试内容的。

 

所以直接注释掉  sync_print_pt(s, pt, true);  打印，问题就可以解决，我们来看看解决问题之后，cat /sys/kernel/debug/sync文件的效果：

 

ctyun_ty1_x64:/ $ cat /sys/kernel/debug/sync                                                                                                                               
objs:
--------------
fences:
--------------
[0000000000000000] goldfish_sync:gensym:1739: signaled

[0000000000000000] goldfish_sync:gensym:1741: signaled

[0000000000000000] goldfish_sync:gensym:7544: signaled

[0000000000000000] goldfish_sync:gensym:7546: signaled

[0000000000000000] FramebufferSurface:0: signaled

[0000000000000000] com.android.launcher3.adapt/:2: signaled

信息比ARM要全面，能够打印各个fence情况了。

再次执行Bugreport也不会导致系统崩溃，至此问题解决。