一个内核oops问题的分析及解决

最近在调试设备时，遇到了一个偶发的开机死机问题。通过查看输出日志，发现内核报告了oops错误，如下所示（中间省略了部分日志，以......代替）：

Unable to handle kernel NULL pointer dereference at virtual address 0000000c
pgd = cdd90000
[0000000c] *pgd=8df4d831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] SMP ARM
CPU: 0 PID: 206 Comm: mount Tainted: P           O   3.18.20 #4
task: ced40e40 ti: cdf7c000 task.ti: cdf7c000
PC is at exfat_fill_super+0xc8/0x4cc [exfat]
LR is at exfat_fill_super+0x48/0x4cc [exfat]
pc : [<bf64b670>]    lr : [<bf64b5f0>]    psr: a0080013
sp : cdf7de48  ip : ffffffff  fp : c0744a30
r10: 00000001  r9 : bf652dac  r8 : 00008000
r7 : cdf80000  r6 : cf302000  r5 : cdf85000  r4 : cdf41000
r3 : 00000000  r2 : cdf85104  r1 : 00000003  r0 : 000001b5
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8dd9006a  DAC: 00000015

SP: 0xcdf7ddc8:
ddc8  cfa70880 fffffffc 0000000b cf17f800 cf4ea000 cf17f600 00000000 cfdee780
dde8  bf64b670 a0080013 ffffffff cdf7de34 00008000 c0012e18 000001b5 00000003
......
Process mount (pid: 206, stack limit = 0xcdf7c238)
Stack: (0xcdf7de48 to 0xcdf7e000)
de40:                   00000001 cdf41000 cdf7deb0 cf17f60c 00000001 00008000
de60: cdf41000 cdf7c038 c0744a30 c0264164 bf652db4 cdf7de84 3b9aca00 00000004
de80: cf4ea6c0 00000083 cf4ea734 cf302000 cf4ea6c0 00000083 00008000 cdf41000
......
dfc0: 01197040 01197040 be9fff49 00000015 be9fff31 00008000 00000000 00000000
dfe0: b6e3d2e0 be9ffaf8 0007ebec b6e3d2f0 60080010 be9fff49 00000000 00000000
[<bf64b670>] (exfat_fill_super [exfat]) from [<c00d12ec>] (mount_bdev+0x168/0x190)
[<c00d12ec>] (mount_bdev) from [<bf64b0ac>] (exfat_fs_mount+0x18/0x20 [exfat])
[<bf64b0ac>] (exfat_fs_mount [exfat]) from [<c00d1fd4>] (mount_fs+0x14/0xcc)
[<c00d1fd4>] (mount_fs) from [<c00ea480>] (vfs_kern_mount+0x4c/0x104)
[<c00ea480>] (vfs_kern_mount) from [<c00ed214>] (do_mount+0x194/0xb54)
[<c00ed214>] (do_mount) from [<c00edf1c>] (SyS_mount+0x74/0xa0)
[<c00edf1c>] (SyS_mount) from [<c000e4e0>] (ret_fast_syscall+0x0/0x38)
Code: e5851108 e3a01003 e593300c e5933308 (e1d330bc)

从上述日志信息中，初步可以看出，在挂载exfat格式文件系统的存储卡时，内核出现了空指针访问问题，最终导致内核奔溃并输出oops。因为之前没有遇到过这个问题，且最近硬件更换了读卡器，存储卡也更新换代了，从之前的100MB/s换到了120MB/s，所以，最初怀疑问题可能是因为更换读卡器或（和）存储卡导致的。但是，硬件和卡的变更到底是如何影响并导致上述oops错误的，这其中的细节并不清楚。好在堆栈信息比较明确，异常时，PC指针指向了这个位置：exfat_fill_super+0xc8/0x4cc（PC is at exfat_fill_super+0xc8/0x4cc [exfat]）。

学习直通车：Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈

那我们就顺藤摸瓜，看看这个位置对应的代码是什么。首先，在工程中搜索exfat_fill_super这个函数，了解其位置和关联模块。一番操作下来，发现这个函数在第三方开源库exfat中。这个库提供了exfat文件系统挂载的支持，并被编译为ko库文件，在系统启动时insmod到系统中。其次，我们看看问题日志中，PC指针指向的代码具体是哪一行？因为日志中只提示在exfat_fill_super这个函数的0xc8偏移处，为了准确找到这个位置，我们需要借助gdb，如下所示：

(gdb) l exfat_fill_super
sb->s_d_op = &exfat_dentry_ops;
}
   #endif
static int exfat_fill_super(struct super_block *sb, void *data, int silent)
{
struct inode *root_inode = NULL;
struct exfat_sb_info *sbi;
int debug, ret;
long error;
(gdb) l *exfat_fill_super+0xc8
0x9670 is at ./exfat-nofuse-master/exfat_super.c:2301.
int option;
char *iocharset;

opts->fs_uid = current_uid();
opts->fs_gid = current_gid();
opts->fs_fmask = opts->fs_dmask = current->fs->umask;
opts->allow_utime = (unsigned short) -1;
            opts->codepage = exfat_default_codepage;
opts->iocharset = exfat_default_iocharset;
opts->casesensitive = 0;

可以看到，gdb告诉我们，0xc8偏移在2301这一行（也告诉我们对应的汇编在0x9670处，后面会用到）：

2301       opts->fs_fmask = opts->fs_dmask = current->fs->umask;

但是，比较烦人的是，这行代码是连续赋值，并且都使用到了指针，所以并不能一下就确定问题到底在那一个赋值上产生。不过，不着急，我们先看看这行代码做了什么。按照C语言的规则，连续赋值是从右到左执行，所以先执行的应该是：

opts->fs_dmask = current->fs->umask;

执行这行代码时，需要先确定current->fs，再确定fs->umask，最后，将结果给opts->fs_dmask。所以，就这一处赋值而言，就有三个可能的疑点。先看第一个current->fs。

这里current是一个宏，用于获取当前线程的任务结构体（这里又隐藏一个指针）。

#define get_current() (current_thread_info()->task)
#define current get_current()

对于当前arm平台，线程信息是通过堆栈寄存器获取的。

static inline struct thread_info *current_thread_info(void)
{
register unsigned long sp asm ("sp");
return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
}

从上面代码，进一步的得知，线程信息是堆栈寄存器通过位运算获得的。这里的THREAD_SIZE定义如下：

#define THREAD_SIZE_ORDER 1#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)

这是一个跟页面大小相关的量。在当前系统中，PAGE_SIZE为4KB大小，所以THREAD_SIZE为8KB大小，也即0x2000，一共14位。减去1，就是1FFFF，取反就是0b’0000（第一个0占1bit，其余为4bit），然后参与“与”运算。

这一连串的运算，总结为一句话，就是将给定的栈指针地址的低13位与0进行与运算，即将栈指针低13位清零。这就是说内核线程结构体是在当前栈8KB对齐的低地址处。这是内核在设计时故意安排的，可以提高查找效率。我们来看这个指针获取是否存在空指针访问的问题：

current_thread_info()->task

回到最开始的日志中，部分信息如下

task: ced40e40 ti: cdf7c000 task.ti: cdf7c000
PC is at exfat_fill_super+0xc8/0x4cc [exfat]
LR is at exfat_fill_super+0x48/0x4cc [exfat]
pc : [<bf64b670>]    lr : [<bf64b5f0>]    psr: a0080013
sp : cdf7de48  ip : ffffffff  fp : c0744a30

其中，sp在cdf7de48，所以thread_info的位置应该是cdf7c000，从上面的日志中也可以看到ti是cdf7c000，所以这个位置不会是空指针的位置。这里的task是thread_info结构体的一个子域，如下

struct thread_info {
unsigned long     flags;    /* low level flags */
int          preempt_count; /* 0 => preemptable, <0 => bug */
mm_segment_t      addr_limit;    /* address limit */
struct task_struct *task;    /* main task structure */
struct exec_domain *exec_domain;  /* execution domain */

那么，task有没有可能是一个空指针呢？上面oosp的日志也给出了，task: ced40e40，所以，task也不为空。

这样，current就指代了这里的task，一个不为空的地址。所以我们再看current->fs这里的fs是task_struct结构体的一个子域struct fs_struct *fs;（部分字段省略）

struct task_struct {
volatile long state;   /* -1 unrunnable, 0 runnable, >0 stopped */
void *stack;
atomic_t usage;
unsigned int flags;    /* per process flags, defined below */
unsigned int ptrace;
   ......
/* CPU-specific state of this task */
struct thread_struct thread;
/* filesystem information */
struct fs_struct *fs;
/* open file information */
struct files_struct *files;
/* namespaces */
struct nsproxy *nsproxy;
   ......
#ifdef CONFIG_PERF_EVENTS
struct perf_event_context *perf_event_ctxp[perf_nr_task_contexts];
struct mutex perf_event_mutex;
struct list_head perf_event_list;
#endif
#ifdef CONFIG_DEBUG_PREEMPT
unsigned long preempt_disable_ip;
#endif
   ......
};

从上面的定义，可以看到，它是跟文件系统相关的一个结构体。分析到这里时，考虑到问题所在函数为exfat_fill_super，看名字似乎是填充文件系统超级快的操作，加之测试部门反馈，问题出现后，格式化存储卡就会恢复，所以我怀疑，会不会是因为更换读卡器和存储卡，导致读取超级块信息有误，才使得文件系统相关访问出现空指针，并报告oops。为了验证这一想法，我将上述连续赋值的这行代码（即前述问题所在的2301行代码）进行拆分，分为多条语句，然后在每一个指针使用点添加日志，以便在问题出现时，输出问题到底在哪个指针上。另外，为了尽可能保留环境，在问题出现后，采取软重启设备，并通过重新配置uboot参数，让内核通过nfs挂载根文件系统，这样就可以替换之前的ko库文件来测试了。奇怪的是，每次替换后，问题就不出现了。这一现象似乎打破了之前的猜测，感觉问题又偏向软件一侧了。在这种取巧的打印方案没有取得效果后，我决定直接分析汇编代码，看看问题出现时，空指针到底落在了哪里。反汇编目标文件，结合gdb报告的位置（前面已提到）和oops中报告的指令内容

Code: e5851108 e3a01003 e593300c e5933308 (e1d330bc)

确定问题就在下面汇编中9670这一行：

9660:  e5851108   str    r1, [r5, #264] ; 0x1089664:  e3a01003   mov    r1, #39668:  e593300c   ldr    r3, [r3, #12]966c:  e5933308   ldr    r3, [r3, #776] ; 0x3089670:  e1d330bc   ldrh   r3, [r3, #12]9674:  e1c2c0bc   strh   ip, [r2, #12]9678:  e1c200be   strh   r0, [r2, #14]967c:  e1c230ba   strh   r3, [r2, #10]9680:  e1c230b8   strh   r3, [r2, #8]

这是一条加载指令，即将r3寄存器指示的内存地址，偏移12位置后的两个字节，加载到r3寄存器中。这里r3指示的内存地址是什么呢？根据oops中给出的信息，是00000000，加上12，就是地址0000000C，所以oops报告

Unable to handle kernel NULL pointer dereference at virtual address 0000000c

结合C代码及问题点前后的汇编代码，直观感觉，这里的12应该是一个结构体中某一个子域的偏移，找到这个偏移对应的域，那么就可以确定是在哪一个赋值上出现了空指针。

回到C代码，问题代码行前后有好几个结构体使用，为了快速确定偏移，我选择参考内核container_of宏，定义一个找偏移的宏

#define my_offsetof(TYPE, MEMBER)  ((size_t)&((TYPE *)0)->MEMBER)

通过这个宏，快速找到每一个元素在结构体中的偏移。当然，也可以通过看代码来确定，但是没有这种方法来得快。就是通过这个操作，引出了问题的最终原因。我们继续。添加获取偏移的日志后，得到的相关偏移信息如下：

task_offset=12, fs_offset=904, umask_offset=12, fs_fmask=8, fs_dmask=10

这里的12、904、12、、8、10似乎跟汇编有隐隐的对应关系。但是这里的904跟776没有什么关系。我决定再看看添加日志后目标文件的反汇编代码，如下：

97b8:  e3a0b000   mov    fp, #0
97bc:  e3a0207b   mov    r2, #123   ; 0x7b
97c0:  e3000000   movw   r0, #0
97c4:  e300a000   movw   sl, #0
97c8:  e5933388   ldr    r3, [r3, #904] ; 0x388
97cc:  e3400000   movt   r0, #0
97d0:  e340a000   movt   sl, #0
97d4:  e1d330bc   ldrh   r3, [r3, #12]
97d8:  e1c930ba   strh   r3, [r9, #10]
97dc:  e1c930b8   strh   r3, [r9, #8]
97e0:  e5cb2000   strb   r2, [fp]
97e4:  e595300c   ldr    r3, [r5, #12]

因为此时代码被修改，所以只能大概判断之前问题所在的汇编范围。从上面可以看出，这一次汇编里的数值跟打印出来的偏移对应上了。根据这次的偏移，结合汇编，基本可以确定，之前出问题的汇编对应的就是C代码中的fs->umask这个语句因为fs为空，所以再去获取umask，就会报空指针异常。那问题来了，为啥fs会变空呢？有经验的读者，此时可能已经猜出问题的原因了。

我们看到，之前代码反汇编后，fs的偏移是776，添加日志重新编译后，反汇编成了904。虽然添加日志，导致代码被修改，但是并不影响这个偏移，所以，这里的fs偏移可能就是问题所在。

对于偏移变化，我考虑了三个因素，分别进行了验证：

1 是ko库文件因为flash坏块或其他原因，导致二进制文件部分bit翻转。实际验证后，排除了这个原因。

2 是ko库针对不同平台编译的，放置错误导致。实际验证后，这个原因也排除了。

3是当前添加日志后所编译ko库，其依赖的内核配置跟之前编译ko库依赖的内核配置相比有更新，也就是内核配置发生了变化（内核版本本身是一致的）。这种情况最常见的就是对内核进行了menuconfig操作。检查fs所在的task_struct结构体，发现其中有很多ifdef，不过都不曾配置过，倒是有一个perf相关的CONFIG_PERF_EVENTS，由于调测性能所需，是后来新配置的。但是这个配置选项在fs结构体后面（见前面task_struct结构体），按理说是不影响fs在整个结构体中偏移的。考虑到task_struct结构体里面包含了很多子结构体，不排除上述perf配置影响了fs前面的某些子结构体而导致fs自己的偏移发生变化。说了这么多，那么到底是不是呢，验证一下就知道了。关闭上述选项，重新编译内核，之后再编译exfat，查看汇编，发现偏移回到了776。Yes，问题就是这里了。最终原因就是内核更新了，但是ko没有更新，导致二者不匹配（旧的ko库从776偏移找fs，但是在新内核中，fs的偏移已经成了904），产生了潜在的问题。问题原因最终是找到了，但是问题产生的过程，其实更值得引起注意：ko库因为也是在内核空间运行，所以需要跟kernel版本匹配起来，做版本一致管理。进一步的，不仅仅是嵌入式领域，桌面端也同样的，如果系统中加载了ko库，当更新kernel时，就需要考虑对ko库的影响。二者需要统一起来看待和管理。