记一次kernel patch(附开源贡献相关)

这篇具有很好参考价值的文章主要介绍了记一次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。文章来源地址https://www.toymoban.com/news/detail-628087.html

到了这里,关于记一次kernel patch(附开源贡献相关)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 如何飞速成为开源贡献者(Contributor)

    型号 :MacBook Pro 内存 :16GB 硬盘 :512GB SSD 处理器 :Apple M2 宿主机CPU架构 :ARM Git版本 :2.39.2 (Apple Git-143) Maven版本 :3.8.8 JDK版本 :17 Git 是一个 分布式版本控制系统 ,用于管理和跟踪文件的变化。它可以帮助开发人员或团队 追踪代码的修改历史、协同开发、管理各个版本

    2024年02月10日
    浏览(44)
  • 持续贡献开源力量,棱镜七彩加入openKylin

    近日,棱镜七彩签署 openKylin 社区 CLA(Contributor License Agreement 贡献者许可协议),正式加入openKylin 开源社区。 棱镜七彩成立于2016年,是一家专注于开源安全、软件供应链安全的创新型科技企业。自成立以来,全面深耕于开源生态及信创产业,依托强大的数据和技术积累,自

    2024年02月14日
    浏览(51)
  • 在Github上成为开源项目贡献者

    什么是GitHub GitHub是一个基于互联网的代码托管平台,它允许开发者存储、管理和共享他们的代码,同时提供了一系列的版本控制工具和协作功能。 GitHub提供了一个中央仓库来存储代码,开发者可以通过Git(一种分布式版本控制系统)将代码推送到仓库中。每个仓库可以包含

    2024年03月13日
    浏览(38)
  • 记一次内存泄漏排查

    最近某项目的服务突然告警,cpu超85%,随后就是服务宕机。交付重启服务后恢复正常但是随后不久又开始告警,特别是白天,严重影响客户业务进行。 1、分析日志 查看日志的过程中发现存在内存溢出(OOM),思考要么存在内存泄漏要么业务上触发了某个接口存在大对象,结

    2023年04月16日
    浏览(52)
  • 记一次死锁问题

    最近在做一个需求,碰到了死锁的问题,记录下解决问题的过程 这个需求要改动一个接口,我这边称为A接口,原先的逻辑是A接口内部会调用c方法,c方法是一个dubbo方法, 现在需要再A接口里添加调用B方法,b方法是本地调用。 A接口的入参是某个商品的编码,拿到这个商品编

    2023年04月26日
    浏览(54)
  • 记一次git冲突解决

    在提交mr的时候突然遇到了conflict,这时候意识到没有及时pull代码,脑海中想起了隔壁一起入职的同事经常念叨的一句“每天早上来都pull一下代码”。但是已经迟了 我看了一下,主要是同一个文件,master分支上已经被修改过,然后我要mr的代码也在这个文件上进行了修改。因

    2024年02月05日
    浏览(43)
  • 记一次eduSRC挖掘

    eduSRC是一个专门收录国内高校漏洞的WEB平台,其以审核快,审核效率高而知名,白帽子提交指定高校漏洞并有证书经历以及Rank奖励,Rank可以在平台上换取衣服、键盘、证书等礼物,同样eduSRC的账号也是比较麻烦才能获得的,我研究了一下发现它有两种获取方法: 1、内部人员

    2024年02月05日
    浏览(39)
  • 记一次Flink遇到性能瓶颈

    这周的主要时间花在Flink上面,做了一个简单的从文本文件中读取数据,然后存入数据库的例子,能够正常的实现功能,但是遇到个问题,我有四台机器,自己搭建了一个standalone的集群,不论我把并行度设置多少,跑起来的耗时都非常接近,实在是百思不得其解。机器多似乎

    2023年04月15日
    浏览(78)
  • 记一次翻页性能优化

       由于是公司项目,所以不方便给出代码或者视频,只能列一些自己画的流程图。    大致情况如上,前端有7个显示区。在对其进行滚动翻页的时候,存在以下问题:    通过分析代码,调查log发现,翻页切换平均耗时在600ms。其主要的业务逻辑如下: 主要问题有

    2024年02月05日
    浏览(48)
  • 记一次重大的问题解决

    我们是需要的操作两个git仓库的的三个分支(此处第一个仓库简称:A(负责程序的第一层进入),第二个简称B(负责业务的执行)) 大致就是A的代码引用了B,B的代码引用了A,互为对方的jar包。 问题(部署到测试域之后): 1:请求打进来之后,有时候进,有时候不进,有

    2024年02月21日
    浏览(53)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包