Linux 驱动 probe 失败时资源清理策略是什么，devm_* 如何简化清理？｜诺瓦星云 Linux 驱动面经解析

60 秒回答模板

probe 里通常会申请内存、映射寄存器、获取 clock/regulator/gpio、注册 IRQ、注册子设备等。如果中途某一步失败，已经申请成功的资源必须按相反顺序释放，否则会泄漏、重复注册或硬件状态残留。传统写法是每一步失败 goto 到对应标签，逆序 free、iounmap、free_irq、clk_disable、regulator_disable。devm_* 系列把资源挂到 struct device 的 devres 列表上，比如 devm_kzalloc、devm_ioremap_resource、devm_request_threaded_irq、devm_gpiod_get；probe 返回失败或设备 remove 时，内核会自动按逆序释放这些 managed resources，减少错误路径样板代码。注意 devm 不是万能的：硬件已经启动、runtime PM、工作队列、子设备注册、buffer 对外暴露等副作用仍可能需要显式停止和注销。

考点 错误展开

难度 真实面经题

回答目标 证明自己能写出可重试、可卸载、错误路径可靠的 Linux 驱动初始化代码。

深入解析

失败路径要逆序清理

probe 是分阶段初始化。第 N 步失败时，前 N-1 步的资源已经生效，必须按依赖关系反向撤销，避免后续重试或卸载时状态不一致。

手动 goto 标签容易漏

传统错误处理需要很多 err_free_x 标签。写得清楚可以工作，但资源多时很容易漏掉某条失败路径或释放顺序错误。

devm 绑定设备生命周期

devm 资源记录在 device 的 devres 栈里。probe 失败、驱动解绑或设备销毁时，内核自动释放，释放顺序通常与申请顺序相反。

仍要处理非托管副作用

devm 只管理资源释放，不自动理解硬件状态机。已经启动的 DMA、定时器、工作队列、runtime PM 引用、注册到其他子系统的对象可能仍要手动停止或注销。

易错点

probe 中途失败直接 return，漏释放之前申请的资源。
以为使用 devm 后所有硬件副作用都会自动撤销。
没有按申请依赖的逆序释放，或先释放父资源后仍访问子资源，导致错误路径二次故障。
remove 路径和 probe 失败路径行为不一致，重复释放或漏停中断。

面试官追问

devm_request_irq 后还需要 free_irq 吗？

通常不需要手动 free_irq，设备释放时会自动释放；但如果要在设备生命周期结束前提前停止中断，需要显式禁用或释放。

为什么有些资源不用 devm？

有些资源生命周期不是整个 device，或者释放顺序需要精确控制，或者涉及外部可见对象和硬件状态，手动管理更清晰。

如果面试官让你现场排查，你会先看哪些证据？

我会先看 dmesg 和返回码，再查 /sys 下设备、驱动和资源状态，必要时加 trace/ftrace 或最小日志，先证明问题出在设备生成、匹配、资源获取、回调路径还是用户态交互。