前言
本周事儿挺多,原先计划的代码开发一行也没写啊,又写文档,又参加会议各种评审,代码review, 然后又支持了几个客户,问题定位修改验证的。
简要挑两三个事简单聊一下。
ARM CPU指令支持情况获取
在代码review的时候,发现代码直接调用一些指令,不考虑CPU差异,在一些机型下报非法指令的错误,会导致用户程序崩溃。对于不支持的平台上就应该屏蔽掉该功能。
本来建议使用的lscpu,通过grep获取flags对应的指令,比如aes,然后编译时通过宏控制,对不支持的功能不进行编译,或者进行代码报错处理。发现这样编译的程序不通用,需要为不通的机型编译不同的二进制程序,最好能动态获取指令支持的情况。
上面这个机器是在龙蜥实验室临时借用的阿里云机器,想要学习的同学可以访问
https://lab.openanolis.cn/
注册个账号试试,也支持付费使用的。
通过网络搜索,查找到了getauxval方法。
1 |
|
可以看到支持的情况跟lscpu一致。
在中断函数中使用spinlock避免panic
有客户使用linux的xfrm框架处理ipsec流报文,发现在大流量的情况下,内核会挂死,但是小流量的情况下又很正常。由于使用的是我们的驱动,问题就反馈到我这儿了。
大概看了一下Oops的调用栈,大概就是进程切换导致的死锁。然后到驱动对应的函数看了一下,结合调用栈里的irq函数,大概原因就清楚了。就是在中断处理函数中调用了mutex_lock这个函数,会导致任务切换。而中断执行到一半切出去,就没有办法再切回来的,因为本身切回来也要中断触发的,而在中断处理的过程中,中断实际已经被关掉了。
知道原因了,剩下就好办了,把相关的struct mutex修改成struct spin_lock。相关加锁也使用spin_lock_irqsave替换。最后,发给客户验证一下,确认问题解决了。
正常是要自己验一下,但是xfrm这个框架不了解,需要一些学习成本,记一个待办任务吧。
秉着我们遇到的问题别人肯定都遇到过的思想,到内核找一下其他厂商的代码确认了一下,人家的确都是用的spinlock。哈哈,又挖了一个前人埋的雷。排查一下代码,好家伙,每个项目都有问题,下周又有的忙了。
至于为啥小流量没有问题,只可能是业务处理不频繁的时候,没有触发任务切换。
uboot启动环境
本来产品基本都使用的UEFI+ACPI的形式了,奈何用户说他们只使用uboot+设备树。客户就是上帝啊,那就找了一堆人,拉操作系统的/固件的,一起整出了个uboot启动的环境,还得自己编uImage和设备树。人家本来就对uboot方式投入很少,也没有现成的环境,我们只能硬着头皮去推动了。
本来很简单的,主要就是mkimage把image生成uImage,使用dtc把dts转换为dtb,最后使用bootz启动就好了。结果,各种环境起不来,bootloader和设备树改了好多版本,终于把单numa的测过了。多numa的环境又不对,起来后只有一个numa,下周也还有的忙的了。
更多
本周就是事儿突然多了起来,前面欠的债都回来找你了。当然,这也是好事啊,说明自个儿做的产品有人在用了,准备造福社会了,哈哈。
学习上面,写的第一篇论文经过多个日夜的5个版本的迭代修改,终于批改合格了,上半年软考就剩一个多月了,还得快马加鞭的复习啊!
行动,才不会被动!
欢迎关注个人公众号 微信 -> 搜索 -> fishmwei,沟通交流。
博客地址: https://fishmwei.github.io
掘金主页: https://juejin.cn/user/2084329776486919