Linux 4.1内核热补丁乐成实践

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

难点一： 热补丁建造

这次热补丁在布局体新增了spinlock成员变量，那就涉及新成员的内存分派和开释，在布局体实例被复制和开释时，都要特另外对新成员做处理赏罚，稍有漏掉也许会造成内存走漏进而导致宕机，这就加大了风险。

再一个就是，布局体实例是在历程启动时初始化的，对付已经存在的实譬喻何塞进新的spinlock成员？所谓兵来将挡水来土掩，我们想到可以在原生补丁行使spinlock成员的代码路径上拦截，假如发明实例不含该成员，则举办分派、初始化、加锁、开释锁。

要办理题目，既要攀缘坚苦的山峰，又得节制隐藏的风险。团队编写了剧本举办几百万次的加载、卸载热补丁测试，并无内存走漏，单机不变运行，再下一城。

难点二：难以复现

另一个困难是该题目难以复现，只有在现网出产情形才有几个case可验证热补丁，而又不行以拿用户的情形去冒险。针对这种环境我们已经有尺度化处理赏罚流程去应对，那就是计划完美的灰度计策，这也是UCloud内部一向在夸大的焦点理念和手段。颠末说明，，这个题目可以拆解为验证热补丁不变性和验证热补丁正确性。于是我们采纳了如下灰度计策：

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

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

3. 全网改观：最后再分批在现网情形呆板上打热补丁，执行全网改观，题目获得基础办理，此处要感激运维同窗的尽力帮忙。

（编辑：湖南网）

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