主要观点总结
本文记述了一次由socket buffer（skb）异常导致的内核故障排查过程。文章详细描述了问题的出现、定位、恢复和解决过程，最终确定是第三方内核模块sn_core_odd引发了故障，原因是内核版本升级后skb_make_writable接口的变化。
关键观点总结
关键观点1: 问题描述
文章首先描述了问题的出现，即在升级内核版本后，搜索服务频繁出现内核故障，这些故障仅发生在午夜0点，并且涉及skb的异常。
关键观点2: 问题定位
通过分析和定位，发现故障是由于skb结构体成员异常导致的内核恐慌问题，具体表现为skb的len小于其data（payload）的长度。
关键观点3: 故障分析
通过分析多例vmcore信息，发现触发故障的skb总是与unbound-anchor服务相关。进一步分析发现，故障发生在IP协议栈处理完成之后，由此确定是netfilter中的sn_core_odd模块引发了故障。
关键观点4: 解决方案
最终确定是第三方内核模块sn_core_odd引发了故障，原因是内核版本升级后，skb_make_writable接口的变化。解决方案可能需要调整第三方模块以适应新的内核版本，或者进行eBPF化以降低维护成本并避免稳定性风险。
文章预览
阿里妹导读 本文记述了一次由 skb（socket buffer）异常导致的内核故障排查过程。 起初，没有人在意这个工单。这不过是个别机器的崩溃、一些数据包的迷失、一次服务的中断。直到这场灾难开始和每个人息息相关。 零点敲响的神秘钟声 2024年5月13日，晴。急促的钉声从破旧的 macbook 中骤然响起，在钉群混乱的信息流中，强而有力且坚持不懈的 ding 展现了它的实力，不达，一位日渐肥胖的网络工程师，大致还原了事情的全貌。 从集团升级内核版本开始，集团搜索服务就开始陷入频繁的内核故障，这些故障呈现出诡异但异常明显的规律，仅发生在午夜 0 点，然后如泥牛入海，不见其踪。而 618 的钟声即将敲响，每日 300+ 例频繁的宕机，还有进一步扩大的趋势。这时，没有丰富工作经验的同学肯定会着急忙慌的开始寻根问底, 而处理故障时长长达 2 年半
………………………………
