1. 从 4.4 到 5.4定时器这块到底动了哪些筋骨做过嵌入式 Linux 底层开发的人大概都有过这种体验项目跑了好几年内核一直停在 4.4 或者 4.9某天因为新硬件支持、安全补丁或者供应商要求不得不把内核往 5.4 这个 LTS 版本上迁。迁之前觉得不就是改改版本号、调调配置的事真动手了才发现光是定时器这一块就能让你调上好几天。我自己前阵子刚把一个跑了三年多的设备驱动从 4.4 挪到 5.4整个过程踩的坑不算少尤其是 timer 相关的改动表面上看 API 还在编译也能过但运行起来的行为差异能让你怀疑人生。这篇文章就把我在这次迁移中关于定时器部分的经验完整梳理一遍从 API 变化、数据结构调整、行为差异到实际调试方法尽量讲透。如果你手头正好有 4.4 的内核代码要往 5.4 上搬或者你只是好奇两个 LTS 版本之间定时器子系统到底改了什么这篇内容应该能帮你省下不少翻代码和查邮件列表的时间。我会尽量用实际代码和调试过程来说话而不是只列一堆 API 名字。2. 先搞清楚 4.4 和 5.4 的定时器体系有什么本质区别2.1 4.4 时代的定时器接口长什么样在 4.4 那个年代内核里用定时器基本上就是一套非常经典的模式。你定义一个struct timer_list然后用init_timer()初始化接着给function和data字段赋值最后add_timer()把它挂进去。如果要周期性的定时器就在回调函数里重新mod_timer()一下。这套流程在 4.4 上跑了无数驱动稳定得很。/* 4.4 风格的定时器初始化 */ struct timer_list my_timer; init_timer(my_timer); my_timer.function my_timer_callback; my_timer.data (unsigned long)dev; my_timer.expires jiffies HZ; add_timer(my_timer);这段代码在 4.4 上编译运行都没问题但如果你原封不动搬到 5.4 上编译器会直接给你报错因为init_timer()这个宏在 5.4 里已经被移除了。这不是简单的改名而是整个初始化哲学发生了变化。2.2 5.4 的定时器初始化方式为什么变了5.4 里定时器的初始化统一走timer_setup()这个宏。它的核心思路是把初始化变成一步到位的事情同时引入类型检查机制。你不再需要手动给function和data赋值而是通过宏参数一次性完成。/* 5.4 风格的定时器初始化 */ struct timer_list my_timer; timer_setup(my_timer, my_timer_callback, 0); my_timer.expires jiffies HZ; add_timer(my_timer);回调函数的签名也变了。4.4 时代回调是void (*)(unsigned long)你通过data字段传自定义数据。5.4 里回调变成了void (*)(struct timer_list *)你要拿自定义数据得用from_timer()宏从 timer 指针反推回去。/* 5.4 的回调写法 */ static void my_timer_callback(struct timer_list *t) { struct my_device *dev from_timer(dev, t, my_timer); /* 在这里操作 dev */ }这个变化乍一看只是写法不同但它背后解决的是一个很实际的问题4.4 那种通过data传unsigned long的方式在 64 位系统上如果传指针倒还好但如果传的是结构体里的某个字段偏移类型安全完全靠开发者自己保证编译器帮不上忙。5.4 的from_timer()宏通过container_of机制让编译器能在一定程度上做类型检查减少那种传错指针导致内核 panic的低级错误。2.3 两个版本定时器核心数据结构的对比除了 API 层面的变化struct timer_list本身的字段也有调整。我整理了一个对照表方便你快速看出差异字段/特性4.4 版本5.4 版本影响初始化函数init_timer()timer_setup()旧接口已移除回调签名void (*)(unsigned long)void (*)(struct timer_list *)必须改函数原型数据传递data字段直接赋值from_timer()反推更类型安全定时器标志无统一标志位TIMER_IRQSAFE等新增行为控制内部实现基于timer_list链表引入timer_base优化性能更好这个表格里最值得注意的是TIMER_IRQSAFE标志。在 4.4 上如果你要在中断上下文里操作定时器得自己保证不会出问题。5.4 引入了这个标志明确告诉内核这个定时器会在 IRQ 上下文里被操作内核会做相应的保护。这个改动对写中断相关驱动的开发者来说是个很实用的增强。3. 迁移过程中最容易踩的五个坑3.1 回调函数签名不改编译直接报错这是最明显但也最容易忽略的问题。很多人拿到 5.4 的代码看到timer_setup()觉得改个名字就行结果回调函数还是按 4.4 的写法来编译器直接甩你一脸错误。/* 错误写法回调还是老签名 */ static void my_callback(unsigned long data) { /* ... */ } timer_setup(my_timer, my_callback, 0); /* 编译报错 */编译器会告诉你参数类型不匹配。这时候你得把回调改成void (*)(struct timer_list *)然后用from_timer()拿数据。我建议在迁移的时候先把所有定时器回调函数列个清单一个个改别想着批量替换能搞定因为每个回调里拿数据的方式都不一样。3.2 from_timer 宏用错运行时直接 panicfrom_timer()这个宏用起来简单但有个前提你传给它的 timer 指针必须是结构体里那个真正的定时器成员。如果你结构体里有多个定时器或者你传错了成员名编译能过但运行起来container_of算出来的地址就是错的然后你访问那个假的结构体指针内核直接 panic。struct my_device { struct timer_list timer_a; struct timer_list timer_b; int value; }; /* 正确从 timer_a 反推 */ struct my_device *dev from_timer(dev, t, timer_a); /* 错误回调是 timer_a 触发的但你用 timer_b 反推 */ struct my_device *dev from_timer(dev, t, timer_b); /* 地址算错 */这个坑我在调试的时候遇到过现象是系统跑一段时间后随机 panic堆栈指向定时器回调。后来用printk把t和dev的地址打出来才发现from_timer算出来的地址跟实际结构体地址差了 8 个字节。所以用这个宏的时候一定要确认成员名跟实际触发回调的那个 timer 一致。3.3 定时器删除逻辑在 5.4 上行为有差异4.4 里删除定时器用del_timer()或者del_timer_sync()。5.4 里这两个函数还在但行为上有细微差别。del_timer()在 5.4 上如果定时器正在其他 CPU 上运行它不会等你直接返回。而del_timer_sync()会等回调执行完。这个差异在单核系统上不明显但在多核系统上如果你在模块卸载的时候用del_timer()而不是del_timer_sync()可能出现回调还在跑、但你的模块数据已经被释放的情况然后就是 use-after-free。模块退出路径里删定时器一律用del_timer_sync()别图省事用del_timer()。这个习惯在 4.4 上可能没出过事但在 5.4 的多核调度下出事的概率会明显上升。3.4 jiffies 比较方式在 5.4 上有新要求4.4 时代很多人写定时器判断直接用if (time_after(jiffies, my_timer.expires))这个写法在 5.4 上依然能用。但 5.4 更推荐用time_after_eq()或者直接依赖定时器框架本身的到期判断。如果你在回调里手动重新计算expires要注意 jiffies 回绕的问题。/* 4.4 常见写法5.4 也能用但要注意回绕 */ my_timer.expires jiffies HZ; /* 5.4 更推荐用辅助宏 */ my_timer.expires jiffies msecs_to_jiffies(1000);msecs_to_jiffies()这个宏在两个版本里都有但 5.4 对它的实现做了优化转换效率更高。如果你原来用HZ直接算迁移的时候可以顺手改成msecs_to_jiffies()代码可读性更好也不容易算错。3.5 高精度定时器 hrtimer 的接口也有调整虽然这篇主要讲传统 timer但很多驱动里会混用 hrtimer。5.4 的 hrtimer 接口跟 4.4 比也有变化主要是hrtimer_init()的参数和回调返回值处理。如果你代码里用了 hrtimer迁移的时候也得一起改。/* 4.4 hrtimer 初始化 */ hrtimer_init(my_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); my_hrtimer.function my_hrtimer_callback; /* 5.4 写法类似但回调返回值枚举有调整 */ hrtimer_init(my_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); my_hrtimer.function my_hrtimer_callback;hrtimer 的回调返回值在 5.4 里还是HRTIMER_RESTART和HRTIMER_NORESTART但内部处理逻辑有优化。如果你原来依赖某些边界行为迁移后最好重新测一遍。4. 一个完整迁移案例的代码拆解4.1 迁移前的 4.4 驱动代码假设我们有一个虚拟设备驱动里面用了一个定时器做周期性轮询。4.4 上的代码大概长这样/* 4.4 版本 */ struct my_device { struct timer_list poll_timer; int poll_interval; void *reg_base; }; static void my_poll_callback(unsigned long data) { struct my_device *dev (struct my_device *)data; /* 读取寄存器 */ read_register(dev-reg_base); /* 重新调度 */ dev-poll_timer.expires jiffies dev-poll_interval; add_timer(dev-poll_timer); } static int my_probe(struct platform_device *pdev) { struct my_device *dev; dev devm_kzalloc(pdev-dev, sizeof(*dev), GFP_KERNEL); init_timer(dev-poll_timer); dev-poll_timer.function my_poll_callback; dev-poll_timer.data (unsigned long)dev; dev-poll_timer.expires jiffies HZ; add_timer(dev-poll_timer); return 0; }这段代码在 4.4 上跑得很好但直接拿到 5.4 上编译init_timer未定义回调签名也不对。4.2 迁移到 5.4 后的对应代码改成 5.4 风格之后代码变成这样/* 5.4 版本 */ struct my_device { struct timer_list poll_timer; int poll_interval; void *reg_base; }; static void my_poll_callback(struct timer_list *t) { struct my_device *dev from_timer(dev, t, poll_timer); /* 读取寄存器 */ read_register(dev-reg_base); /* 重新调度 */ mod_timer(dev-poll_timer, jiffies dev-poll_interval); } static int my_probe(struct platform_device *pdev) { struct my_device *dev; dev devm_kzalloc(pdev-dev, sizeof(*dev), GFP_KERNEL); timer_setup(dev-poll_timer, my_poll_callback, 0); mod_timer(dev-poll_timer, jiffies HZ); return 0; }注意几个关键变化回调参数从unsigned long data变成了struct timer_list *t取设备结构体用from_timer()重新调度用mod_timer()而不是手动改expires再add_timer()。mod_timer()在 5.4 里对已经激活的定时器处理更高效推荐用它替代手动操作。4.3 迁移后必须验证的三个行为点代码改完编译通过只是第一步下面这三个行为点必须实际跑起来验证第一定时器首次触发时间是否准确。4.4 和 5.4 的 jiffies 初始化和 HZ 配置可能不同如果你的驱动依赖精确的首次触发时间得用示波器或者高精度日志确认一下。第二周期性调度的间隔是否稳定。在 4.4 上你可能习惯了定时器间隔有少量抖动5.4 的定时器子系统做了优化抖动应该更小但如果你的代码里有其他地方关中断时间过长还是会影响精度。第三模块卸载时定时器是否正确停止。在remove函数里一定要调del_timer_sync()然后确认回调不会再执行。我一般会在回调里加一个标志位卸载时先置标志再删定时器双保险。static int my_remove(struct platform_device *pdev) { struct my_device *dev platform_get_drvdata(pdev); del_timer_sync(dev-poll_timer); /* 确认回调不会再跑 */ return 0; }5. 调试定时器问题的实用手段5.1 用 ftrace 跟踪定时器回调执行5.4 的 ftrace 对定时器子系统的支持比 4.4 好很多。你可以直接开timer相关的 trace event看每个定时器的启动、到期、回调执行时间。# 查看可用的定时器 trace 事件 ls /sys/kernel/debug/tracing/events/timer/ # 开启定时器启动和到期事件 echo 1 /sys/kernel/debug/tracing/events/timer/timer_start/enable echo 1 /sys/kernel/debug/tracing/events/timer/timer_expire_entry/enable # 查看 trace 输出 cat /sys/kernel/debug/tracing/trace这个手段在排查定时器为什么没按时触发或者回调为什么执行了两次这类问题时特别有用。4.4 上也有 ftrace但 timer 相关的事件没这么细。5.2 用 printk 加时间戳定位延迟问题如果你怀疑定时器回调被延迟了可以在回调入口和出口加printk带上jiffies和ktime_get()的时间戳。static void my_poll_callback(struct timer_list *t) { struct my_device *dev from_timer(dev, t, poll_timer); unsigned long entry_jiffies jiffies; pr_info(timer entry: jiffies%lu, ktime%lld\n, entry_jiffies, ktime_get_ns()); /* 实际工作 */ read_register(dev-reg_base); pr_info(timer exit: jiffies%lu, delta%lu\n, jiffies, jiffies - entry_jiffies); mod_timer(dev-poll_timer, jiffies dev-poll_interval); }通过对比expires和实际 entry 的 jiffies你能算出调度延迟。如果延迟经常超过几个 jiffy说明系统里有其他地方在长时间关中断或者关抢占得去查那些地方。5.3 检查内核配置里定时器相关的选项从 4.4 迁到 5.4make oldconfig之后一定要检查这几个配置项配置项4.4 默认5.4 默认建议CONFIG_HZ常见 100 或 250常见 250 或 1000根据延迟需求选CONFIG_HIGH_RES_TIMERS通常开启通常开启保持开启CONFIG_TIMER_STATS可选已移除用 ftrace 替代CONFIG_NO_HZ_IDLE可选推荐开启省电但注意延迟CONFIG_TIMER_STATS在 5.4 里已经被移除了原来依赖这个选项做统计的代码得改成用 ftrace。CONFIG_NO_HZ_IDLE在 5.4 上更成熟开启后空闲 CPU 会停掉 tick省电效果明显但如果你对定时器唤醒延迟敏感得实测一下是否满足要求。6. 迁移完成后的回归测试清单6.1 功能层面的必测项代码改完、编译通过、基本功能跑通之后下面这些测试项一个都不能少定时器首次触发时间是否符合预期误差在可接受范围内周期性定时器连续运行 24 小时观察是否有漏触发或间隔漂移模块加载卸载循环 100 次确认没有内存泄漏和定时器残留系统进入 suspend 再 resume定时器行为是否正常恢复多核并发场景下定时器回调是否出现竞态这些测试在 4.4 上可能跑一遍就过了但在 5.4 上由于调度器和定时器子系统的改动某些边界情况的行为会不一样。我自己的经验是suspend/resume 这一项最容易出问题因为 5.4 对系统休眠时的定时器处理逻辑做了调整。6.2 性能层面的对比测试如果你原来的驱动对定时器精度有要求迁移后最好做一次性能对比。用cyclictest或者自己写一个简单的延迟测量程序在 4.4 和 5.4 上分别跑看延迟分布有没有明显变化。# 简单的定时器延迟测试思路 # 在用户态用 timerfd 模拟或者直接在内核模块里统计根据我的实测5.4 在定时器精度上比 4.4 有改善尤其是在高负载场景下延迟抖动更小。但这个改善的前提是你的内核配置合理如果CONFIG_HZ设得太低再好的子系统也救不了精度。6.3 长期运行稳定性观察功能测试和性能测试都过了之后别急着收工。把设备跑起来连续运行一周每天检查一次内核日志里有没有定时器相关的 warning 或 error。5.4 的内核在定时器异常时会打印更详细的诊断信息比如 timer didnt expire 或者 callback took too long这些在 4.4 上可能只是静默失败。我一般会在迁移后的第一个月里每周用dmesg | grep -i timer扫一遍日志。这个习惯帮我抓到过一个偶发的定时器重复添加问题在 4.4 上完全没暴露5.4 的调试信息直接指出了问题所在。7. 一些个人体会和后续可以深入的方向这次迁移做完我最大的感受是内核版本升级从来不是改改 API 就完事的事情。定时器这块的变化表面上是init_timer变成timer_setup回调签名变了但背后是整个内核对类型安全、多核并发、电源管理的思路在演进。你如果只按编译错误一个个改能跑起来但跑得好不好、稳不稳定是另一回事。另外5.4 的定时器子系统跟工作队列、tasklet 的交互也有变化如果你驱动里混用了这几种延迟机制迁移的时候得一起考虑。我接下来打算把工作队列部分的迁移经验也整理一下那块踩的坑不比定时器少。最后说一个很实用的小技巧迁移的时候别一次性把所有定时器代码都改完再编译。按模块来改一个、编一个、测一个出问题了容易定位。我一开始图快一口气改了五个文件结果编译错误混在一起光理清依赖关系就花了半天。后来改成逐个模块推进效率反而高了很多。