Linux 4.1内核热补丁成功实践

而本次热补丁修复存在两个难点：

难点一： 热补丁制作

这次热补丁在结构体新增了spinlock成员变量，那就涉及新成员的内存分配和释放，在结构体实例被复制和释放时，都要额外的对新成员做处理，稍有遗漏可能会造成内存泄漏进而导致宕机，这就加大了风险。

再一个就是，结构体实例是在进程启动时初始化的，对于已经存在的实例如何塞进新的spinlock成员？所谓兵来将挡水来土掩，我们想到可以在原生补丁使用spinlock成员的代码路径上拦截，如果发现实例不含该成员，则进行分配、初始化、加锁、释放锁。

要解决问题，既要攀登困难的山峰，又得控制潜在的风险。团队编写了脚本进行几百万次的加载、卸载热补丁测试，并无内存泄漏，单机稳定运行，再下一城。

难点二：难以复现

另一个难题是该问题难以复现，只有在现网生产环境才有几个case可验证热补丁，而又不可以拿用户的环境去冒险。针对这种情况我们已经有标准化处理流程去应对，那就是设计完善的灰度策略，这也是UCloud内部一直在强调的核心理念和能力。经过分析，，这个问题可以拆解为验证热补丁稳定性和验证热补丁正确性。于是我们采取了如下灰度策略：

1. 稳定性验证：先拿几台机器测试正常，再拿公司内部500台次级重要的机器打热补丁，灰度运行几天正常，从而验证了稳定性，风险尽在掌控之中。

2. 正确性验证：找到一台出现问题的机器，同时打印utime+stime以及rtime，根据代码的逻辑，当rtime小于utime+stime时会执行老逻辑，当rtime大于utime+stime时会执行新的热补丁逻辑。如下图所示，进入热补丁的新逻辑后，utime+stime打印正常且与rtime保持了同步更新，从而验证了热补丁的正确性。

3. 全网变更：最后再分批在现网环境机器上打热补丁，执行全网变更，问题得到根本解决，此处要感谢运维同学的全力协助。

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!