★ FEATURED ARTICLE 1. 为什么把大模型拉进内核驱动审查这件事值得认真做做Linux内核驱动开发的人都有一个共同体会写代码的时间可能只占三成剩下七成全耗在审查和返工上。尤其是drivers/staging这个目录它本身就是内核社区用来孵化不稳定驱动的缓冲区代码质量参差不齐风格五花八门提交频率还高。一个staging驱动的补丁从提交到真正被maintainer接受中间可能要经历五六轮甚至十几轮修改每一轮都是人工逐行看、逐条回。这种重复性极高的审查劳动恰好是大语言模型擅长的事情。我所在的团队过去大半年一直在做一件事把LLM嵌入到drivers/staging驱动代码的审查流程里让它承担第一道筛查人只做第二道把关。实测下来一个中等规模的驱动补丁人工初审平均要40分钟LLM预审加人工复核能压到15分钟左右而且漏掉的低级问题明显变少了。这篇内容就是把这套策略和实践完整拆开讲清楚——它适合谁适合有一定内核开发基础、正在维护或提交staging驱动、想用LLM提升审查效率的开发者也适合刚接触内核补丁流程、想搞清楚什么样的代码会被打回的新手因为LLM预审给出的意见本质上就是一份高频错误清单。需要先说明一点LLM不是万能的它不能替代checkpatch.pl也不能替代维护者的架构判断。它的定位是不知疲倦的初级审查员负责把格式、常见模式、明显逻辑漏洞这些机械性工作干掉把人的精力释放到真正需要经验的地方。理解这个定位后面的所有策略才有意义。2. 整体方案设计与思路拆解2.1 为什么选staging目录作为切入点内核那么多子系统为什么偏偏从drivers/staging下手这不是随便挑的。staging目录的代码有几个天然特征让它成为LLM辅助审查的理想试验田。第一问题密度高。staging里的驱动大多是厂商丢过来、社区接手维护的半成品TODO文件里明晃晃写着需要清理编码风格需要替换过时API需要补充错误处理。这意味着LLM随便扫一遍都能抓到一堆问题验证效果特别快。第二审查标准相对明确。staging的准入门槛比drivers/net、drivers/gpu这些成熟子系统低维护者对什么该改有比较清晰的清单很多规则是机械性的比如pr_info要不要带模块名前缀、kmalloc之后有没有判空、copy_from_user的返回值有没有检查。这些恰好是LLM能稳定判断的。第三反馈闭环短。staging补丁的review周期通常比核心子系统短LLM给出的建议对不对一两周内就能从邮件列表的回复里得到验证方便我们持续调优提示词。反过来如果一上来就拿mm/或者fs/这种核心子系统练手LLM稍微给个似是而非的建议就可能误导人风险太高。所以选staging是先易后难的稳妥路径。2.2 三层审查架构的取舍逻辑我们没有让LLM直接对着整个补丁自由发挥而是设计了三层结构每一层职责清晰第一层确定性工具。checkpatch.pl、sparse、smatch这些老牌工具先跑一遍把缩进、行宽、空格、类型标注这些纯机械问题过滤掉。这一层不消耗LLM的token也不该消耗。第二层LLM语义审查。把补丁的diff、相关上下文函数、以及一份审查要点清单一起喂给模型让它输出结构化的意见按严重程度分级。第三层人工复核。维护者只看LLM标记为高优先级的条目以及自己凭经验觉得可疑的地方。这个分层的关键考量是成本与准确率的平衡。checkpatch.pl跑一次几乎零成本且100%确定没理由让LLM去干这个。LLM的价值在于它能理解这段probe函数的错误处理路径是不是漏了clk_disable这种需要跨行推理的问题而这正是静态工具的死角。把两者混在一起让LLM全包既浪费钱又降低可靠性。提示三层架构里第一层的输出也要喂给LLM作为上下文。比如告诉模型checkpatch已经报过行宽问题你不用重复能显著减少无效输出。2.3 提示词工程的核心原则这套方案里最花时间的不是搭流程而是调提示词。踩了无数坑之后我总结出几条硬原则。原则一给角色但别给太多角色。一开始我们写你是一位资深Linux内核维护者精通驱动开发、内存管理、并发控制……结果模型开始过度发挥连驱动业务逻辑都要点评。后来改成你是drivers/staging的初审员只关注以下清单内的问题清单外的一律不评论输出立刻收敛。原则二清单要具体到可判定。检查错误处理这种指令等于没说。要写成检查每个可能失败的系统调用kmalloc、copy_from_user、request_irq、platform_get_irq等的返回值是否被判断若未判断则标记为高优先级。模型对可判定的规则执行得非常好。原则三强制结构化输出。要求模型按固定格式返回比如每条意见包含文件:行号、问题类型、严重程度、建议修改。结构化之后才能做后续的自动聚合和去重也方便人工快速扫读。原则四让它说不确定。明确告诉模型如果某处需要了解硬件手册或业务背景才能判断就输出需人工确认而不是硬猜。这一条把误报率降了一大截。3. 核心审查清单与实操要点3.1 内存与资源管理类检查这是staging驱动翻车最集中的地方也是LLM表现最好的领域因为规则明确、模式固定。kmalloc/kzalloc返回值判空是最基础的一条。LLM能稳定识别出ptr kmalloc(...); ptr-field x;这种没判空就解引用的写法。但要注意一个坑有些代码用了devm_kzalloc这是设备管理资源失败时返回NULL但通常紧接着就return -ENOMEMLLM有时会误报未判空。解决办法是在提示词里明确区分devm_*系列和普通kmalloc系列的处理惯例。资源释放路径的对称性是更考验模型的地方。比如probe函数里先clk_prepare_enable再request_irq如果request_irq失败必须clk_disable_unprepare。这种跨多行的配对关系静态工具很难查LLM却能顺着错误分支一路追下去。我们实测让模型专门做错误路径资源泄漏检查在几十个真实补丁上抓出了三处人工初审漏掉的regulator未disable问题。copy_from_user/copy_to_user返回值必须检查且返回值是未拷贝的字节数判断逻辑是if (ret)而非if (ret 0)。这个细节LLM偶尔会搞混需要在清单里写死正确写法。检查项严重程度LLM识别稳定性备注kmalloc未判空高很稳定需排除devm系列错误路径资源泄漏高较稳定需提供完整函数上下文copy_from_user返回值高稳定注意判断逻辑kfree后继续使用高中等依赖控制流分析重复释放高中等复杂分支易漏3.2 并发与锁的正确使用并发问题比内存问题难因为很多错误不是语法层面能看出来的而是这个锁保护的范围对不对这种语义判断。LLM在这里的能力边界要心里有数。它能稳定抓的是明显的锁使用错误spin_lock之后调用了可能睡眠的函数比如kmalloc(GFP_KERNEL)、copy_from_user、mutex在中断上下文里使用、加锁后某条return路径忘了解锁。这些模式相对固定模型见过大量类似代码判断准确率不错。它不太可靠的是锁粒度是否合理、是否存在隐蔽的竞态窗口。这类问题需要理解驱动的状态机LLM容易给出看起来有道理但实际不成立的建议。我们的做法是让LLM只标记疑似由人工定夺绝不让它直接下结论。实操中有一个很有效的技巧把驱动里所有锁的声明和初始化部分作为上下文一起喂给模型让它先建立这个驱动有哪些锁、分别保护什么的认知再去审查具体函数。这比只给单个函数片段的效果好很多因为它能发现这个函数用了dev-lock但同文件其他函数保护同一数据结构用的是dev-io_lock这类不一致。3.3 内核API的过时用法识别staging目录里大量存在十年前甚至更早的API用法这是历史包袱。LLM在这方面的价值特别突出因为它训练数据里既有老代码也有新代码能识别出这个接口已经被替换了。典型例子包括create_proc_entry应换成proc_create、init_timer应换成timer_setup、get_drvinfo这类旧网络接口的淘汰、do_gettimeofday应换成ktime_get_real_ts64。这些替换关系相对固定LLM识别得很准而且能顺带给出新接口的调用示例。但要注意版本敏感性。同一个API在不同内核版本里的推荐写法可能不同必须告诉模型目标内核版本。我们一开始没指定版本模型给出的建议混着好几个版本的习惯维护者看了直摇头。后来在提示词里固定目标为当前主线版本输出就统一了。注意过时API的替换建议一定要让模型附上该接口在哪个版本被移除/替换的依据人工复核时先核对这个依据能挡掉大部分幻觉。3.4 编码风格与提交信息规范这部分本来checkpatch.pl能覆盖大半但有两块是它管不了的提交信息的质量和代码注释的有效性。提交信息方面内核社区要求subject行简洁、正文说清为什么改而不只是改了什么。LLM很擅长把一段潦草的提交信息重写成符合规范的版本也能指出这个补丁的说明里没提为什么要删掉这个函数。我们让模型专门检查提交信息是否包含问题背景、是否说明了影响范围效果不错。注释方面staging代码里常见注释和代码对不上的情况比如注释说返回0表示成功代码实际返回负数表示成功。LLM能对照注释和实现找出矛盾这类问题人工审查时反而容易因为看着像对的而滑过去。4. 完整实操流程与关键环节实现4.1 环境搭建与工具链准备整套流程跑在一个普通的开发机上就行不需要什么特殊硬件。核心组件是git拿补丁和上下文、checkpatch.pl内核源码树自带、一个能调用的LLM接口、以及一个把三者串起来的小脚本。先准备内核源码树用来跑checkpatch和提取上下文git clone --depth 1 内核源码仓库地址 linux-src cd linux-src # checkpatch.pl 在 scripts 目录下 ls scripts/checkpatch.pl然后是审查脚本的骨架。我用Python写因为它处理文本和调接口都方便。核心逻辑是读入一个补丁文件先跑checkpatch再把diff和相关函数上下文拼成提示词调模型最后把结果按严重程度排序输出。import subprocess import re def run_checkpatch(patch_path, kernel_dir): result subprocess.run( [perl, f{kernel_dir}/scripts/checkpatch.pl, --no-tree, --strict, -f, patch_path], capture_outputTrue, textTrue ) return result.stdout def extract_context(patch_path, kernel_dir): # 从补丁里解析出涉及的文件和行号回源码树取上下文 # 简化示意实际实现需解析 diff hunk 头 with open(patch_path) as f: diff f.read() files re.findall(r^\\\ b/(.)$, diff, re.M) contexts {} for fp in files: full f{kernel_dir}/{fp} try: with open(full) as f: contexts[fp] f.read() except FileNotFoundError: contexts[fp] return contexts这里有个关键决策上下文给多少。给整个文件token消耗大但模型判断准只给diff省钱但模型容易断章取义。我们的折中是给diff涉及的函数完整代码加上文件头部的宏定义和结构体声明。实测这个粒度在准确率和成本之间平衡得最好。4.2 提示词模板的落地写法提示词是整个流程的灵魂我把它拆成固定模板每次只替换变量部分。模板大致长这样你是 drivers/staging 的初审员。目标内核版本当前主线。 只审查下面清单中的问题清单外不评论。 审查清单 1. 内存分配返回值是否判空devm_* 系列除外 2. 错误路径是否释放已获取的资源clk/regulator/irq/dma 3. copy_from_user/copy_to_user 返回值是否正确检查 4. spin_lock 临界区内是否调用了可能睡眠的函数 5. 加锁路径是否所有 return 都解锁 6. 是否使用了已过时的内核 API 7. 注释与实现是否矛盾 输出格式严格遵守每条一行 [严重程度:高/中/低] 文件:行号 | 问题类型 | 具体描述 | 建议修改 若某处需硬件手册或业务背景才能判断输出 [需人工确认] 文件:行号 | 描述 checkpatch 已报告的问题如下不要重复报告 {checkpatch_output} 补丁 diff {diff} 相关函数上下文 {context}这个模板有几个细节值得说。[严重程度]放在最前面方便后续脚本按级别排序。文件:行号用竖线分隔方便正则解析。明确列出不要重复报告checkpatch的问题能省掉大量冗余输出。最后那个需人工确认的出口非常重要它让模型有了承认不知道的选项而不是硬编一个答案。4.3 结果聚合与人工复核的衔接模型返回的原始文本不能直接丢给人看得先聚合。我的脚本会做三件事按严重程度排序、按文件分组、把同一文件同一行号的重复意见合并。def parse_and_rank(raw_output): lines [l for l in raw_output.splitlines() if l.strip().startswith([)] high, mid, low, manual [], [], [], [] for l in lines: if 需人工确认 in l: manual.append(l) elif 严重程度:高 in l: high.append(l) elif 严重程度:中 in l: mid.append(l) else: low.append(l) return high, mid, low, manual人工复核时维护者先看high列表逐条判断接受还是驳回。这里有个经验驳回的理由要记下来定期回看这些驳回记录能发现提示词哪里需要收紧。我们前两周的驳回率高达40%大部分是模型对devm_*系列的误判把这条规则在提示词里写死之后驳回率降到15%以下。复核完的结论还要回写到补丁的review记录里形成LLM建议—人工裁决的对照数据。这批数据积累到一定量可以用来微调模型或者优化提示词是整个流程持续变好的燃料。4.4 一个真实补丁的审查走查拿一个典型的staging驱动补丁走一遍能看清各环节怎么配合。假设补丁给某个字符设备驱动加了一个ioctl分支里面kmalloc了一块缓冲区、copy_from_user拷数据、处理完kfree。checkpatch先跑报了两处行宽超限和一处else后接大括号的风格问题这些直接进低优先级列表。LLM拿到diff和ioctl函数全文输出三条高优先级意见第一kmalloc后没判空就copy_from_user判空缺失第二copy_from_user失败的分支直接return -EFAULT但没kfree缓冲区资源泄漏第三copy_from_user的返回值判断写成了if (ret 0)实际应判断if (ret)。三条都精准命中人工复核全部接受。同时模型输出一条需人工确认ioctl命令号的定义方式看起来和驱动其他命令不一致但需要确认是否遵循了本驱动的命令号分配约定。这条人工一看确实不一致但属于历史遗留本次补丁不改标记为后续清理项。整个走查下来LLM在五分钟内给出了人工初审四十分钟才能得出的核心结论人只需要做确认和边界判断。这就是这套流程的价值所在。5. 常见问题与排查技巧实录5.1 模型幻觉与误报怎么压幻觉是LLM审查绕不开的问题表现是言之凿凿地指出一个不存在的问题。我们遇到最多的是模型脑补了上下文里没有的代码比如断言这里缺少mutex_unlock但实际解锁在函数末尾、只是没在给的上下文片段里。压制幻觉最有效的办法是给足上下文。前面说的给完整函数就是为此。如果函数太长至少给到所有return路径和函数末尾。另一个办法是要求模型引用原文让它指出问题所在的具体代码行如果它引用的行在上下文里找不到这条意见直接丢弃。这个校验能挡掉相当一部分凭空捏造。误报则是另一类问题模型指出的问题真实存在但不算问题比如把devm_kzalloc的未判空当成错误。这类要靠细化清单解决把每个检查项的例外情况写清楚。我们的清单从最初7条膨胀到现在的20多条大部分是在补例外。5.2 长补丁的上下文超限处理一个改动上千行的补丁全塞进上下文会超模型窗口。我们的处理策略是按函数切分把补丁拆成若干个函数级审查单元每个单元单独送审最后合并结果。这样既控制了单次输入长度又保证了每个函数有完整上下文。拆分的边界要小心如果一个函数的改动依赖另一个函数里新加的宏或结构体字段拆分后模型可能看不懂。解决办法是在每个单元的上下文里额外附上补丁中新增的宏定义和结构体变更。这部分是全局变更摘要每个单元都带一份。对于跨函数的逻辑改动比如把资源分配从A函数挪到B函数函数级拆分就力不从心了。这种情况我们单独走一次架构级审查只给diff摘要和涉及函数的签名让模型判断改动是否破坏了原有的资源生命周期。准确率不如函数级但能起到提示作用。5.3 审查意见与维护者判断冲突时怎么办这是实践中最微妙的部分。LLM说该改维护者说不该改听谁的我们的原则是LLM的意见是输入不是裁决。冲突时以维护者判断为准但要把冲突记录下来分析。冲突大致分三类。第一类是模型对社区惯例理解不到位比如它建议给某个函数加__init标注但该函数在运行时也会被调用。这类冲突说明提示词需要补充社区惯例知识。第二类是模型过于保守把可以改进当成必须修改比如建议把printk换成dev_info这确实是好实践但并非阻塞性问题。这类要在严重程度上降级。第三类是模型真的发现了维护者疏忽的问题这类最有价值要重点复盘为什么人工漏了。我们每周花半小时过一遍冲突记录把第一类和第二类的规律沉淀进提示词第三类则作为案例在团队内分享。这个复盘机制是整套流程能持续进化的关键没有它LLM审查很快就会退化成每次都报同样一堆无关痛痒的问题人也就懒得看了。5.4 常见问题速查表现象可能原因处理办法大量devm_*误报未判空清单未排除devm系列提示词明确排除报告不存在的解锁缺失上下文不完整补全函数末尾上下文过时API建议版本混乱未指定目标版本提示词固定版本长补丁输出截断超出上下文窗口按函数拆分送审重复报告checkpatch问题未告知已检查项把checkpatch输出喂入对业务逻辑过度点评角色设定过宽收窄为清单内审查严重程度判断失准未定义分级标准清单内写明各级定义5.5 几个踩过的坑和独家心得第一个坑是过早信任模型的严重程度分级。早期我们完全按模型给的高/中/低排序结果发现它把风格问题标成高、把真正的资源泄漏标成中。后来我们自己定义了一套分级标准写进提示词涉及内存安全、资源泄漏、并发正确性的一律高涉及API过时、错误处理不完整的中纯风格的低。模型按这个标准重新分级后排序才靠谱。第二个心得是用历史补丁做回归测试。每次改完提示词拿一批已经人工审过的历史补丁重跑看新提示词是抓得更多还是误报更多。这个回归集我们维护了大约五十个补丁覆盖各类典型问题改提示词前必跑一遍。没有这个回归集调提示词就是盲人摸象。第三个心得是别让LLM碰它不擅长的领域。我们试过让它审查设备树的compatible字符串是否匹配驱动里的of_match_table理论上这是字符串比对应该很简单但实际因为涉及多个文件的交叉引用模型经常张冠李戴。后来这类跨文件一致性检查改用脚本做精确匹配LLM只负责它擅长的单文件语义审查。工具各司其职比让一个工具包打天下靠谱得多。第四个心得关于成本控制。全量审查所有补丁的token开销不小我们的做法是分级触发小补丁改动少于50行只跑checkpatch加轻量LLM审查中等补丁跑完整流程超大补丁先人工粗筛再决定是否送LLM。这样把成本压到了可接受范围同时保证了重点补丁的审查深度。6. 把LLM审查嵌入日常流程的几点实践建议这套东西跑顺之后最大的感受是LLM审查的价值不在于替代人而在于改变人的注意力分配。以前维护者要花大量精力在机械性问题上现在这些被前置过滤掉人的注意力集中在架构合理性、业务逻辑正确性这些真正需要经验的地方。审查质量整体是上升的不只是效率提升。如果要在自己的项目里落地我的建议是从小处开始。先挑一个你熟悉的staging驱动手动跑几次LLM审查对比它给出的意见和你自己的判断摸清它在你的场景下的能力边界。边界清楚了再决定把它放在流程的哪个位置。别一上来就搞全自动化LLM的输出直接进邮件列表那样一旦误报多了维护者会对整个方案失去信任再想推就难了。提示词的维护是个长期活。内核在演进社区惯例在变模型也在更新提示词里的清单和例外需要定期回看。我们现在的做法是每月过一遍驳回记录把新发现的误报模式补进清单。这件事看着琐碎但它是整套方案保持有效的根本。最后说一个我个人的判断LLM辅助代码审查这件事在驱动这种规则密集、模式固定的领域落地价值是实打实的。它不会让审查变得不需要人但会让人的审查变得更有针对性。把机械劳动交给模型把判断留给自己这个分工在可预见的将来都是成立的。
阅读完成 · 觉得有帮助？
