给 linux 提 patch 必踩的坑

记第一次给 linux 提 patch，鸣谢 swing 大人。

普通贡献者给 linux 提 patch 一般不直接发 PR，而是通过邮件列表来和 subsystem 的维护者们联系。正常流程往往会经历多轮 review、讨论和重新修改。一开始上手交patch的时候特别容易踩坑😭

提 patch 大约有这些流程：

定位问题 → 编写 patch → 发送邮件 → review & 更新 patch

官方的教程在这里

LLM 辅助发现了bug，如何提交

If you resorted to AI assistance to identify a bug, you must treat it as public. While you may have valid reasons to believe it is not, the security team’s experience shows that bugs discovered this way systematically surface simultaneously across multiple researchers, often on the same day. In this case, do not publicly share a reproducer, as this could cause unintended harm; just mention that one is available and maintainers might ask for it privately if they need it.

linux kernel sec team 发现，LLM 经常在相近时间发现同一个bug，所以可以把bug视作公开，直接在公共渠道提交 patch 即可。如果已经在公开 mailing list 发了补丁，就不用再发送给 security@kernel.org 了。

参考

写代码的时候要小心 kernel coding style，我提交的 [patch 里面]((https://lore.kernel.org/netdev/20260903141204.40934-1-yilinzhang@moonshot.ai/) 大括号的风格不符合规范，被维护者指出来了。不过还不能马上发 v2，因为 netdev 要求两个版本之间至少间隔 24 小时，要给不同时区的 reviewer 留出足够的 review 时间

   while ((fq = rhashtable_walk_next(&hti))) {
+    int refs = 0;
+
     if (IS_ERR(fq)) {
       if (PTR_ERR(fq) != -EAGAIN)
         break;
       continue;
     }
     spin_lock_bh(&fq->lock);
-    if (!(fq->flags & INET_FRAG_COMPLETE))
+    if (!(fq->flags & INET_FRAG_COMPLETE)) {
+      inet_frag_kill(fq, &refs);
+    }
+
+    if (fq->flags & INET_FRAG_HASH_DEAD)
       inet_frag_queue_flush(fq, 0);
     spin_unlock_bh(&fq->lock);
+    inet_frag_putn(fq, refs);
   }

   rhashtable_walk_stop(&hti);

在内核这种复杂系统里面，写这个补丁的时候，需要考虑非常多的加锁、功能影响…

写邮件

（提前去邮件列表看看最近没有人提过相似的 patch）

不同的 subsystem 有自己的公开邮件列表，例如 netdev 的公开邮件列表就在这里查看：https://lore.kernel.org/netdev/

因为邮件是公开的，所以里面不可以包含敏感 exp 信息，也要注意发送规范不要加重维护者的负担。

对于一个漏洞 patch 大概要有这些内容：

代码问题
漏洞影响
decode 的 KASAN log
patch 代码本身

邮件发给谁（to），应该抄送哪些人（cc）？

可以用这个脚本来确定一下要发送的维护者

./scripts/get_maintainer.pl -f drivers/net/ethernet/foo/foo.c

也可以看历史的 patch 看看邮件应该发给谁，对于抄送，一般需要 cc 邮件列表。如果是 Link 提到的提交用户也应该加入 cc。

署名写什么

Fixes：指出这个 bug 是由哪个历史 commit 引入的。
Reported-by：表示是谁最先报告或发现了这个问题。
Signed-off-by：表示提交者确认符合 DCO，并对这份代码的来源和提交负责。
Tested-by：表示某人实际测试过这个 patch，并确认它在其测试环境中正常工作。
Reviewed-by：表示某人完整 review 过这个 patch，并认可当前实现。
Suggested-by：表示 patch 中采用的关键思路或解决方案来自某人的建议。
Co-developed-by：表示这个 patch 是由多人共同开发完成的，通常需要配套对应的 Signed-off-by。
Assisted-by：表示开发过程中使用了 AI 或其他高级代码辅助工具参与分析、生成或修改代码。

如何发送邮件

虽然说很多邮箱说自己有纯文字功能（比如飞书），但是提交 patch 的时候最好不要用，因为一些邮箱可能会把英文符号改成中文编码（比如飞书），这样的话 patch 就坏了。

最好配一个 smtp，使用 git send-email 发送：

[sendemail]
  smtpServer = smtp.example.com
  smtpServerPort = 587
  smtpEncryption = tls
  smtpUser = you@example.com

这里的最大坑是这一封邮件

通过飞书邮件发送，邮件编码把 patch 搞坏了，最后只能换成 Git 的邮件工具重新发后续版本，msg-id 也特别长…

修改和讨论

Kernel mailing list 一般使用 inline reply，而不是 top posting。例如

> Could this use foo_valid() instead?
Yes, this is cleaner. I'll change it to foo_valid() in v2.

为了给维护着足够的时间检查补丁，最好间隔 24 小时再发第二封补丁（这个是 netdev subsystem 的规定），即使某个维护者秒回了，也要等到 24h 确保其他人也可以看见。比如下面这个就被 bot 骂了：

1. [PATCH v2] tcp: fastopen: check rsk_drop_req() in tcp_fastopen_create_child()
   - by Yilin Zhang @ 2026-09-03  9:40 UTC [13%]

···

5. [PATCH] tcp: fastopen: check rsk_drop_req() in tcp_fastopen_create_child()
   - by Yilin Zhang @ 2026-09-02 12:12 UTC [13%]

如果提交了 v2 以上的 patch，还需要在邮件的补丁部分注明，不同版本有什么区别

Signed-off-by: Author <author@mail>
---
v3:
  - Remove redundant helper function.
  - Preserve the original refcounting semantics.
v2: <https://lore.kernel.org/>...
  - Clean up coding style.
  - Address review comments.
v1: <https://lore.kernel.org/>...

--- 后面的 changelog 只服务于邮件 review，不会进入最终 Git commit message。

btw，如果邮件列表讨论时，有人提了一些建议被采用了，应该在署名的部分加上 suggested-by，给对方 credit。

LLM 辅助发现了bug，如何提交

首先是要写一个 patch

写邮件

邮件发给谁（to），应该抄送哪些人（cc）？

署名写什么

如何发送邮件

修改和讨论