说了这么多,那么到底是不是呢,验证一下就知道了。关闭上述选项,重新编译内核,之后再编译exfat,查看汇编,发现偏移回到了776。Yes,问题就是这里了。
最近在调试设备时,遇到了一个偶发的开机死机问题。通过查看输出日志,发现内核报告了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 : [] lr : [ ] 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 [ ] (exfat_fill_super [exfat]) from [ ] (mount_bdev+0x168/0x190) [ ] (mount_bdev) from [ ] (exfat_fs_mount+0x18/0x20 [exfat]) [ ] (exfat_fs_mount [exfat]) from [ ] (mount_fs+0x14/0xcc) [ ] (mount_fs) from [ ] (vfs_kern_mount+0x4c/0x104) [ ] (vfs_kern_mount) from [ ] (do_mount+0x194/0xb54) [ ] (do_mount) from [ ] (SyS_mount+0x74/0xa0) [ ] (SyS_mount) from [ ] (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])。那我们就顺藤摸瓜,看看这个位置对应的代码是什么。
首先,在工程中搜索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 : [] lr : [ ] 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] ; 0x108 9664: e3a01003 mov r1, #3 9668: e593300c ldr r3, [r3, #12] 966c: e5933308 ldr r3, [r3, #776] ; 0x308 9670: 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库的影响。二者需要统一起来看待和管理。
原文来自:https://os.51cto.com/article/708740.html
本文地址:https://www.linuxprobe.com/oops-core-jieju.html编辑:问题终结者,审核员:逄增宝
Linux命令大全:https://www.linuxcool.com/
Linux系统大全:https://www.linuxdown.com/
红帽认证RHCE考试心得:https://www.rhce.net/