Linux 内核的 staging 子树最近被一条消息带到了很多开发者面前这个专门用来收留“半成品驱动和实验代码”的子系统开始拒绝由 LLM 生成的补丁唯一例外是真正的安全修复。这条规则表面上只影响少数向 drivers/staging 提交补丁的人但它背后的问题——LLM 补丁的可信度、安全补丁的特殊通道、以及内核社区对 AI 生成代码的态度——对嵌入式开发者、驱动开发者和 LLM 使用者都很有参考价值。下面从 staging 子系统的定位讲起梳理规则的背景、标准补丁提交链路、安全修复例外以及开发者应该如何处理自己的补丁。1. 这则消息到底在说什么Staging Area 不是 Git 暂存区很多人看到 Staging Area第一反应是git add之后的暂存区。但结合 Linux 内核开发语境这里更可能指的是 Linux 内核源码树中的drivers/staging目录。理解这一点才能理解为什么一条关于“拒绝 LLM 补丁”的消息会让不少驱动开发者讨论起来。1.1 先理解内核里的 staging 子树drivers/staging是内核代码树里的一个特殊目录。它存在的意义是让尚不够成熟、但已经可以运行的驱动或框架先进入内核源码树从而让外部开发者更容易参与测试也能让代码被更多人 review。很多硬件驱动在正式进入主目录前都会先在 staging 里待一段时间。staging 并不意味着代码可以随便写它只是把“正在开发”和“已经稳定”区分开。进入 staging 的门槛比正式目录低但维护者仍然会检查基本结构和潜在风险。正因如此staging 往往也是新手提交第一个内核补丁的地方。很多学习嵌入式 Linux 和驱动开发的人第一次接触内核社区就是从这个目录开始。1.2 拒绝 LLM 补丁拒绝的是什么标题里的“Reject LLM Patches”写成完整说法是staging 子系统的维护者会拒绝“由大型语言模型自动生成或者主要由 LLM 生成的补丁”除非这些补丁是真正的安全修复。这里的“拒绝”并不是说 git 命令会失败而是指维护者在收到补丁后不会再花时间去 review 其中的代码逻辑、格式和修改意图。代码能不能合入在补丁到达邮件列表的那一刻就被决定了。这不是一次技术上的编译失败而是信任链条上的中断。为什么 LLM 补丁会被这样对待因为内核审查关注的不只是代码能不能编译还包括补丁是否解决了真实问题、是否经过测试、签名是否有效、提交者是否对自己的改动负责。1.3 为什么安全修复可以例外安全修复被单独拎出来是因为这类补丁有明确的时间压力和危害等级。如果某个漏洞正在被利用厂商和用户都在等修复这时候再要求开发者必须使用非 LLM 方式写补丁反而会延误合入。所以规则写的是“真正的安全修复”不是补丁标题里带 security 字样而是代码确实修复了一个可被利用或可造成内核异常的问题并且能够给出清晰的漏洞描述、影响范围和复现信息。但例外不等于降低标准。安全补丁仍然要符合补丁格式、包含 Signed-off-by、走正常的 review 流程。只是维护者允许补丁的来源是“LLM 辅助生成”前提是人类开发者完成了验证和负责到底。2. LLM 补丁为什么会让内核维护者头疼核心问题不是“AI 写的代码不行”而是 LLM 生成的补丁在真实内核开发场景里经常出现几个典型问题。这些问题叠加在一起会让补丁 review 的成本变得非常高。2.1 表面上合理实际上逻辑错误LLM 非常擅长产出一段语法上看起来正常的 C 代码但这种“看起来正常”对内核维护者来说反而是负担。内核代码高度依赖上下文锁是否已经持有、引用计数是否已经增加、设备树属性是否真实存在、头文件是否已经包含。这些上下文信息很难在一个 prompt 里完整描述LLM 很容易在不知情的情况下生成错误修复。举个例子一个初学者很容易写出下面的内存释放逻辑static void free_context(struct drv_context *ctx) { if (ctx) kfree(ctx-data); kfree(ctx); }这个函数的问题很明显ctx-data和ctx的释放顺序是否正确取决于调用者是否希望同时释放 data。如果 data 是共享资源直接这样释放就可能造成 use-after-free。LLM 补丁的问题恰恰在于它不会告诉你这个前提它只会给你一段结构完整的代码。维护者接收补丁后必须自己判断上下文。如果补丁数量很多这种判断成本会指数上升。2.2 补丁格式和授权信息往往不合格内核社区的补丁提交有严格规则最常见的一项是“必须在补丁说明中带有 Signed-off-by 行”。这是开发者证书Developers Certificate of Origin的体现表示提交者有权提交这个补丁并且理解代码来源。LLM 生成的补丁经常缺少这一行或者更严重的是由 LLM 自动填写了一个不存在的名字和邮箱。另一个常见问题是 LLM 补丁会生成无意义的改动调整空格、重命名变量、添加多余注释。这些改动让 diff 变大却没有任何行为变化在维护者眼里就是噪音。下面是一个典型的、看起来标准化但会被直接打回的补丁头部From: ChatGPT chatgptexample.invalid Subject: [PATCH] staging: some_driver: fix typo in comment Signed-off-by: ChatGPT chatgptexample.invalid问题不在于注释里的 typo 是否需要修而在于From和Signed-off-by使用了不存在的身份。内核社区要求补丁提交者使用真实身份和真实邮箱因为后续 bug 需要有人负责。伪造身份会让整个补丁无法被信任。2.3 无效补丁挤占真实审阅资源维护者一天的时间有限。LLM 或 LLM agent 可以批量生成几十封补丁邮件这些补丁如果都以“看起来合理”的形式出现在邮件列表里维护者就不得不逐封打开并判断是否有效。这样一来真正需要关注的 bug 修复和功能补丁反而可能被淹没。这一点在 staging 子树尤其明显因为 staging 本身就是大量新手补丁的入口信噪比一低老手就更不愿意来这里 review。这也是为什么很多内核维护者强调不要为了练习而批量投递 LLM 补丁更不要用自动化脚本把“AI 生成的 patch”全量发到邮件列表。代码贡献的本质是合作不是提交数量。注意一次高质量的补丁提交价值远高于一百封格式正确但内容无意义的 LLM 补丁。对于刚接触内核开发的人来说先熟悉社区规范再谈用 AI 提效。2.4 LLM 补丁的常见特征速查下面这些特征并不代表“一定是 LLM 补丁”但会提高维护者的警惕特征可能原因维护者反应提交者身份难以确认使用生成邮箱或假名直接 NAK修改了多个不相关文件LLM 在一段话里被塞入多个诉求要求拆分补丁没有说明测试过程自动生成后未运行要求补充测试diff 中包含大量空白字符变化模型对格式理解偏差要求去掉无关变化修复逻辑看起来“全对”但缺少上下文说明模型不知道调用前提要求补充分析维护者不是靠“反 AI 检测工具”来识别补丁而是靠这些行为特征。一个补丁如果让维护者产生“这个人真的理解这段代码吗”的疑问就已经很难通过 review 了。3. 内核补丁提交链路从生成到合入需要经过什么如果不想被“拒绝规则”误伤我们需要先把内核补丁的标准提交链路走一遍。对 staging 子系统来说这条链路同样适用。3.1 从源码克隆到分支修改首先需要准备 Linux 内核源码树。常见做法是使用 git 命令克隆并且拉取一个稳定分支作为开发基线。git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux git checkout master git pull然后基于当前 HEAD 创建自己的工作分支git checkout -b staging-fix-example在这个分支上修改代码或文档。改完之后先做一次本地提交提交信息要写清楚“为什么修改”而不是“AI 让我改这里”。3.2 使用 checkpatch 做基础检查内核源码树里自带scripts/checkpatch.pl它可以帮助检查补丁是否符合内核编码风格。在生成 patch 之前先运行它git add . git commit -s -m staging: some_driver: fix potential memory leak in error path git format-patch -1 ./scripts/checkpatch.pl 0001-staging-some_driver-fix-potential-memory-leak-in-err.patch这里的-s参数会在提交信息里自动加上 Signed-off-by 行。运行 checkpatch 后终端会输出是否有 ERROR、WARNING、CHECK。建议至少消除 ERROR 和 WARNING。但不能只依赖这个脚本因为 checkpatch 不检查逻辑正确性。3.3 通过邮件列表发送补丁内核社区不使用 Pull Request而是通过邮件列表发送补丁。最常用的工具是git send-email。发送前需要配置 SMTP 相关参数具体可以参考内核文档Documentation/process/下的指南。git send-email --todeveldriverdev.osuosl.org --cclinux-kernelvger.kernel.org 0001-*.patch这里的收件人列表要按目标子系统填写。staging 子系统的维护者通常在邮件列表develdriverdev.osuosl.org中。发送之后耐心等待维护者和社区成员的 review。如果邮件被回复 NAK不要急着重新发一版先根据反馈修改。3.4 一条完整补丁通常包含什么一个能进入 review 流程的补丁应包括明确的标题staging: 驱动名: 修改类型正文说明问题场景、修改思路、测试情况Signed-off-by 行真实姓名和邮箱可能包含的 Reported-by、Tested-by、Reviewed-by 等标签这些内容共同构成补丁的“上下文”也是维护者判断补丁是否值得 review 的依据。3.5 staging 子树为什么容易被 LLM 补丁盯上staging 子树因为代码质量门槛相对低经常被初学者当作练习入口。LLM 补丁之所以大量涌向这里可能也是因为初学者想让 AI 帮忙改一个驱动却不知道 staging 子树的真实规则。维护者过滤 LLM 补丁本质上是在保护这个入口不被垃圾信息污染。对于真正想提交补丁的开发者这里更需要耐心。staging 下的代码往往带有 TODO、FIXME 或者临时实现维护者优先希望看到能够清掉 TODO 的补丁而不是从 AI 那里抄来的“风格优化”。4. 如果安全修复由 LLM 辅助完成如何避免被拒绝“真正的安全修复”是拒绝规则的例外但如何判断一个补丁是否真的安全修复维护者不会只看标题。提交者需要提供足够的信息。4.1 一个合格安全补丁的构成合格的安全补丁不只包含修复代码还要包含漏洞背景受影响的模块和驱动触发条件攻击者需要什么权限或什么硬件影响越权、崩溃、信息泄露还是内存破坏修复方案为什么这样改能堵住问题测试结果在什么内核版本上验证过注意这里不需要描述漏洞利用过程的细节。写补丁是给维护者看不是给学生出题。漏洞利用细节写太多反而容易被拒绝。4.2 一个可以套用的提交信息模板假设我们修复了一个在某种设备下出现的数组越界问题提交信息可以这样写staging: some_driver: validate channel index before array access The driver parses channel index from hardware register. In some firmware variants, the register can return a value larger than the array size, which leads to out-of-bounds access when reading settings_data[channel]. Add a bounds check and return -EINVAL if the channel index is out of range. Reported-by: 示例用户 userexample.com Signed-off-by: 你的姓名 your.emailexample.com这段信息没有描述具体的错误值也没有给出攻击载荷只说明了“什么条件、什么后果、怎么修”。这是安全补丁的标准表达方式。4.3 明确标注 LLM 辅助的角色如果 LLM 确实参与了代码生成可以在补丁正文中补充说明“This patch is generated with the assistance of LLM and has been manually reviewed by the author.” 这样做并不是为了炫耀而是为了透明。维护者知道补丁来自 LLM 辅助之后会更关注上下文逻辑是否被人验证过。这个备注要用英文并且不能替代 Signed-off-by。但要注意如果维护者已经明确表示“拒绝 LLM 补丁”那么即使补丁是安全修复也不要让它看起来像未经人工审阅的自动生成产物。补丁的署名和“负责者”必须是真实的人。安全修复可以例外但前提是补丁信息足够清楚。与其反复提交一份模糊的安全补丁不如先花十分钟把漏洞背景和触发条件写清楚。4.4 如何验证一个安全修复真的有效提交安全修复前至少做以下验证编译通过最好同时编译相关架构和依赖模块。做一次烟雾测试确认修复没有引入新的崩溃或卡死。如果可能用 kunit 或一个最小的驱动加载脚本覆盖边界条件。检查是否引入了新的 NULL 解引用、内存泄漏或锁问题。验证方式要写进补丁正文。即使只是“编译通过已在某平台上加载测试”也比空口说“这个 bug 修了”可靠得多。内核维护者看到验证记录通常会更愿意继续读下去。5. 面对“拒绝 LLM 补丁”规则开发者应该怎么做这里给出能直接落地的操作建议。如果你平时已经在用 LLM agent 或者 LLM 框架协助开发就更需要注意这些边界。5.1 LLM 在内核开发中的合理使用边界推荐的做法用 LLM 帮助理解陌生代码把某个函数贴给模型让它拆解关键路径。用 LLM 生成测试用例描述模块行为让模型帮忙构造边界输入。用 LLM 做代码走查的辅助把 diff 发给模型让它列出潜在风险再人工验证。不要把 LLM 的输出直接作为补丁提交至少要经过阅读、运行、测试和签名。不推荐的做法让 LLM agent 自动扫描代码并批量生成补丁。使用 LLM 生成一个“看似完成”的修复然后直接提交。在补丁信息中伪造 Signed-off-by 或粘贴不存在的作者。5.2 提交前自检清单自检项完成标准目的补丁是否解决真实问题能说清楚触发场景和修改必要性避免无意义改动是否检查了上下文锁、引用计数、错误处理路径都确认过避免 LLM 生成逻辑错误是否运行过 checkpatch无 ERRORWARNING 尽量清零保证格式符合内核规范是否包含 Signed-off-by使用真实姓名和邮箱完成开发者证书声明是否说明测试结果至少说明编译通过最好有运行验证让维护者信任补丁可靠性是否检查过邮件主题和收件人格式正确且发到对应列表避免补丁被忽略5.3 常见被拒原因与处理建议问题现象常见原因处理建议邮件被回复 NAK没有具体代码意见补丁被识别为 LLM 生成或缺少 Signed-off-by补充真实签名和上下文重新解释改动意图checkpatch 报 ERROR缩进、头文件顺序、提交信息格式不符按脚本输出修改不要忽略补丁没有收到任何回复可能是发错了邮件列表或补丁主题不明确检查git send-email的收件人重新发送或到社区相关论坛询问补丁内容被评价为“无意义”只是格式调整或注释修改优先选择真实 bug 修复不要提交纯格式改动这四条覆盖了新手最容易遇到的情况。实际操作时被拒绝并不可怕可怕的是不知道为什么被拒绝。5.4 一个可复用的提交前检查脚本示例可以把这个脚本当作一个最小检查入口放在内核源码树根目录下使用。它检查补丁是否能干净应用、是否通过 checkpatch、是否包含 Signed-off-by。#!/bin/bash # usage: ./check-patch.sh patchfile PATCH$1 if [ -z $PATCH ]; then echo usage: $0 patchfile exit 1 fi # 1) 检查补丁是否能干净应用并检查空白错误 git apply --check --whitespaceerror-all $PATCH # 2) 使用内核自带 checkpatch 脚本 ./scripts/checkpatch.pl --no-tree $PATCH # 3) 检查补丁中是否存在 Signed-off-by 行 if grep -q ^Signed-off-by: $PATCH; then echo INFO: Signed-off-by found else echo WARN: Signed-off-by missing fi这个脚本只是一个起点。实际提交前还需要人工确认补丁标题、收件人、测试记录和提交信息。把这些做成脚本或检查清单能显著减少因为格式问题被打回的概率。6. 更深层的思考AI 辅助开发与社区信任6.1 代码评审的本质是建立信任内核社区长期依赖“人对人”的 review 机制。一个补丁能不能合入最终看的是维护者是否信任提交者。LLM 补丁的问题不在于代码是 AI 生成的而在于它模糊了“谁对这段代码负责”。提交者如果自己都说不清每一行的含义那么代码合并后出现问题维护者也无法找到合适的负责人。这不是效率问题而是工程责任问题。6.2 从“AI 生成补丁”到“AI 辅助补丁”更好的实践是把 LLM 定位成“辅助工具”而不是“补丁生产者”。你用 LLM 写初稿然后再做深入修改、验证、测试。最终提交的补丁是你的工作成果而不是模型的随机输出。这样既能利用 LLM 提高效率也符合内核社区对补丁署名和责任的期待。在实际开发中可以这样操作先用手写代码或最小修复确定设计方向再用 LLM 处理重复性的格式工作或者让 LLM 从多个角度审查代码最后人工回归测试确认没有破坏边界条件。6.3 对学习内核开发和 LLM 应用开发的共同启发这条规则看起来只针对 Linux 内核但其实对所有开源项目都有参考意义。开源的协作体系建立在“补丁 讨论 信任”之上。无论你是做嵌入式 Linux、驱动开发还是平时用 LLM agent 写代码都要养成同一个习惯让最终提交的每一段代码都经过自己的理解、命名、测试和署名。LLM 能帮你缩小查找范围但它不能替你对项目负责。对于希望提交第一个内核补丁的新手建议是先不要急着用 LLM 生成一个 patch而是先花时间读Documentation/process/submitting-patches.rst和相关文档理解提交流程和邮件列表文化然后再找一个真实的小问题自己动手修提交后根据维护者反馈反复迭代。这个过程比任何 AI 自动生成的补丁都更能建立你在社区里的信任基础。到了这一步就不难理解 staging 子树拒绝 LLM 补丁的真正意图了拒绝的不是人工智能而是未经人类验证的“负责任代码”。真正的安全修复之所以例外是因为安全场景里时间与危害的权衡优先于流程洁癖但即便如此它仍然需要以一个完整、可信、可追溯的形式进入内核。对大多数开发者来说最稳妥的做法始终是让 AI 留在辅助位把署名、判断和改进留给人类自己。