记一次kernel patch（附开源贡献相关）

开源操作系统

看了zhihu上的一些科普，明白二次开发是常见现象，套壳、抄袭、自研都不是很科学的说法。中外大厂都会在AOSP、linux kernel、ffmpeg播放器、chromium等常见的祖先上进行自己的定制，发布自己的发行版。

龙蜥操作系统，来自阿里云，设计目的之一是接管centos留下的烂摊子，用于服务器。
deepin，桌面操作系统。
openharmony和harmonyOS是不同的，类似AOSP与android的关系（剥离开源版和自留版的区别）。

流程手记

首先是smatch。常见的错误如missing unwind goto。此处应该赶紧看一下其它人的报错。

最主要的收获是，失败处理的最佳实践（ABC顺序申请，应CBA顺序释放）。kernel中大量使用这种goto fail label的写法。
trigger_init
buffer_setup
hw_init
hw_stop
buffer_cleanup
trigger_remove

maillist使用、内外审流程相关能大大增加可信度。
内审是学院的Google Group，还邀请了Dan Carpenter；外审直接是maintainer团队了。
maillist，可以认为是不依赖特定软件的群聊。可以用git send email功能，结合获取maintainer功能，快速拉群。
patch生成时会自动拉取commit message里的内容，发送邮件时会使用patch标题。
编译时可以通过调整编译选项，局部编译、多线程编译，大大提高速度。只要确保修改的地方被编译即可。

总结一下流程：
扫描-确认问题是否存在-确认问题修复方案-确认可以编译-写commit message-生成patch-用checkpatch检查patch格式-获取maintainer-发送邮件，如此循环。

smatch能发现的典型问题

Missing unwind goto。kernel中大量使用goto fail label的写法。正确使用goto，可以保证遇到错误之后能妥善处理。以我遇到的问题为例，错误处理代码的资源释放顺序并未对应资源申请顺序。

variable dereferenced before check。在解引用之前应确保值存在。否则内存保护机制会导致程序中断，比如segmentation fault。

dereferencing freed memory。可能导致数据破坏、代码执行。

Dead code。有些分支永远不会到达。比如(npages > (~0)) => (0-u32max > u32max)。

missing error code。以下背景知识经常用到，内核空间最高地址0xffffffff,那么最后一个page就是指的0xfffff000~0xffffffff(假设4k一个page)。这段地址是被保留的linux的错误号，例如最常见的几个 -EBUSY,-EINVAL,-ENODEV,-EPIPE,-EAGAIN,-ENOMEM 之类，其值都位于这个空间。任何一个指针,必然有三种情况,一种是有效指针,一种是NULL,空指针,一种是错误指针。通常的写法是先用IS_ERR()来判断是否是错误,然后如果是,那么就调用PTR_ERR()来返回这个错误代码。如果忘记调用后者，就会报这个错。

常见的修复方案

比较简洁的修复方案，是使用新api，比如Use devm_of_iomap() instead of of_iomap() to automatically handle the unused ioremap region，用devm_kzalloc()代替kzalloc()。这样就无需在函数中考虑失败后的资源释放。

附：偶然发现，unlikely函数

内核中常见unlikely函数（比如判断是否成功，一般都会成功）。

if(unlikely(a))和if(likely(a))的执行等价于if(a)是 一样的，区别在于unlikely和likely函数的加入会优化编译，加likely的意思是value的值为true的可能性更大一些，编译时会将if里的代码编译到紧跟likely判断后面；而unlikely表示value的值为fale的可能性更大一些，编译时会将else下面的代码指令编译到紧跟unlikely判断之后。这样做目的可以提高CPU指令判断效率，减少指令跳转而降低性能。

搞开源贡献的一些捷径

一是用现成工具去扫描。比如JavaFuzzer for java，GFuzz for go，codeQL/cppcheck for c/c++，pyt for python，snyk for 供应链。
二是从上游搬到下游，比如把openJDK搬到bishengJDK。