一、背景

小概率出现kernel异常重启问题：3个月内出现3例报linux kernel地址异常导致重启问题；通过场景分析，构造测试场景，并打开ramdump配置进行复测，抓到了问题现场；

二、crash解析ramdump

2.1 查看出错log

通过dmesg命令抓取log缓存区，找到出错的日志和调用栈；

通过日志中的信息可知，出错位置是cimdma_swap_buffer+0x2a4，以及出错的线程ipi6_thread=>pipeline 8；

2.2 定位出错代码行

加载hobot_cim_dma.ko符号表，并反汇编cimdma_swap_buffer, 找到偏移是0x2a4（676）的指令行；

出错的指令行是strb w25, [x24, w28, uxtw]，结合log中的调用栈，x24: 0000050100000780，说明指令确实是出错点；

再来看X24是怎么赋值的：ldr x24, [x23, #168]，结合log调用和代码hobot_cim_dma_ops.c: 1124

X23的地址便是emb_frame的指针；

2.3 查看出错内存信息

查看emb_frame的内存信息

2.4 找到出错地址的保存位置

通过查看0xffff000180e0b3c0前后的内存信息，是用户设置的配置信息，都是保存在struct cimdma_subdev中，cimdma_subdev是struct j5_cimdma_dev的成员变量

由于通过之前的log已知出错的通路是pipeline 8，对应的结构体是subdev[8]，下一步查看subdev[8]内存信息

X23：ffff000180e0b3c0 是在[ffff000180e0b348]struct vio_framemgr emb_fmgr内，下一步查看emb_fmgr结构体信息

2.5 定位原因

由此可知X23:ffff000180e0b3c0是queued_list[1]的起始地址，queued_list是5个list的list head，queued_list[1]是FS_REQUEST queue，对应代码emb_frame是从FS_REQUEST队列中获取，也就是说peek_frame拿到的是FS_REQUEST队列的head；

通过以上可知，emb_fmgr的链表操作存在的问题，应该是锁保护异常了，重新review代码发现确实是锁异常了，emb_fmgr链表操作时使用了framemgr的spinlock

修改此次的锁异常，便能根本的修复该问题；

三、结论与反思

用锁保护临界资源是多进程并发问题的常用手段，但是锁保护的范围是否正确一直没有有效手段进行检查；在后续的项目或者芯片平台上，用锁保护得增加注释，方便自己其他同学检查，减少出错概率；