https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst
对于希望向Linux内核提交修改的个人或公司而言，若不熟悉相关“规则体系”，整个流程可能会令人却步。本文汇总了一系列建议，能大幅提高你的修改被采纳的概率。
本文档以相对简洁的形式包含了大量建议。如需了解内核开发流程的详细运作机制，请参阅《Documentation/process/development-process.rst》。同时，提交代码前请阅读《Documentation/process/submit-checklist.rst》，核对各项检查清单。若提交的是设备树绑定补丁，请阅读《Documentation/devicetree/bindings/submitting-patches.rst》。
本文档假设你使用 git准备补丁。若你不熟悉 git，建议务必学习其用法——它会让你作为内核开发者的工作乃至日常操作都变得轻松许多。
部分子系统和维护者分支会提供额外的工作流程说明和要求，可参阅《Documentation/process/maintainer-handbooks.rst》。
若你手边没有包含最新内核源代码的仓库，请使用 git获取。建议从主线仓库开始，可通过以下命令克隆：
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
但请注意，你可能无需直接基于主线树进行开发。大多数子系统维护者都有自己的分支，并希望补丁基于这些分支准备。可查看MAINTAINERS文件中该子系统对应的T:条目以找到相关分支，若未列出，直接咨询维护者即可。
说明修改要解决的问题。无论你的补丁是一行代码的bug修复，还是五千行代码的新功能实现，背后都必须有促使你开展这项工作的根本问题。要让审核者相信这个问题值得修复，且有必要继续阅读下去。
阐述对用户可见的影响。直接导致崩溃或死锁的问题很有说服力，但并非所有bug都如此明显。即使问题是在代码审核过程中发现的，也要说明你认为它可能对用户造成的影响。需注意，大多数Linux安装使用的是次级稳定树或厂商/产品专用树的内核，这些内核仅从上游挑选特定补丁，因此请包含所有有助于下游传递你的修改的信息：触发条件、dmesg日志片段、崩溃描述、性能退化、延迟峰值、死锁情况等。
量化优化效果与权衡取舍。若你声称补丁在性能、内存占用、栈空间或二进制文件大小方面有改进，请附上相关数据作为支撑。同时也要说明非显性成本——优化通常并非无代价，而是在CPU、内存和可读性之间权衡，或者对于启发式算法而言，是在不同工作负载之间权衡。请描述优化可能带来的负面影响，以便审核者权衡利弊。
明确问题后，需从技术层面详细说明你具体的解决方案。用通俗易懂的英文描述修改内容，方便审核者验证代码是否符合你的预期行为。
若你将补丁描述写成可直接纳入Linux源代码管理系统（git）的“提交日志”格式，维护者会非常感激。具体可参阅“标准补丁格式”部分。
每个补丁仅解决一个问题。若你的描述开始变得冗长，这可能意味着需要拆分补丁，具体可参阅“拆分修改”部分。
提交或重新提交补丁（或补丁系列）时，请附上完整的补丁描述和修改理由。不要仅说明这是补丁（系列）的第N版，也不要期望子系统维护者查阅之前的补丁版本或相关链接来获取补丁描述并补充到当前补丁中。也就是说，补丁（系列）及其描述应自成一体，这对维护者和审核者都有利——部分审核者可能根本没有收到过之前的补丁版本。
用祈使语气描述修改内容，例如“让xyzzy实现frotz功能”，而不是“[此补丁]让xyzzy实现frotz功能”或“[我]修改了xyzzy使其实现frotz功能”，仿佛是在向代码库下达修改指令。
若需引用特定提交，不要仅提供该提交的SHA-1标识符。请同时附上提交的单行摘要，方便审核者了解相关内容。示例如下：
提交e21d2170f36602ae2708（“video: 移除不必要的platform_set_drvdata()”）
删除了不必要的platform_set_drvdata()调用，但遗留了未使用的变量“dev”，现删除该变量。
同时，请确保至少使用SHA-1标识符的前12个字符。内核仓库包含大量对象，较短的标识符存在冲突风险。需注意，即使当前6个字符的标识符没有冲突，五年后也可能发生变化。
若修改的相关讨论或其他背景信息可在网络上找到，请添加“Link:”标签并附上链接。如果补丁是基于之前的邮件列表讨论或网络上的相关文档开发的，也请提供对应链接。
链接邮件列表归档时，建议使用lore.kernel.org邮件归档服务。创建链接URL时，需使用邮件“Message-ID”头部的内容（不含两侧的尖括号）。示例如下：
Link: https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI
请检查链接是否有效且指向相关邮件。
但请尽量让你的解释不依赖外部资源也能被理解。除了提供邮件列表归档或bug报告的URL外，还需总结导致当前补丁提交的相关讨论要点。
若你的补丁修复了某个bug，请使用“Closes:”标签并附上指向邮件列表归档或公共bug追踪系统中对应报告的URL。示例如下：
Closes: https://example.com/issues/1234
部分bug追踪系统支持在包含此类标签的提交被应用时自动关闭相关问题，一些监控邮件列表的机器人也能跟踪此类标签并执行特定操作。禁止使用私有bug追踪系统或无效URL。
若你的补丁修复了特定提交中的bug（例如通过 git bisect找到的问题），请使用“Fixes:”标签，至少包含SHA-1标识符的前12个字符以及单行摘要。标签不可跨多行书写，为简化解析脚本，标签不受“75列换行”规则限制。示例如下：
Fixes: 54a4f0239f2e（“KVM: MMU: 让kvm_mmu_zap_page()返回实际释放的页面数”）
可通过以下 git config设置，在 git log或 git show命令中输出上述格式的内容：
[core]
abbrev = 12
[pretty]
fixes = Fixes: %h ("%s")
调用示例：
$ git log -1 --pretty=fixes 54a4f0239f2e
Fixes: 54a4f0239f2e（“KVM: MMU: 让kvm_mmu_zap_page()返回实际释放的页面数”）
将每个逻辑修改拆分为独立的补丁。
例如，若你的修改同时包含对单个驱动的bug修复和性能优化，应将这些修改拆分为两个或多个补丁；若修改包含API更新以及使用该新API的驱动程序，也需拆分为两个独立补丁。
反之，若你对多个文件进行了同一逻辑修改，可将这些修改整合为一个补丁。即单个逻辑修改应包含在单个补丁中。
需记住的核心原则是：每个补丁应实现易于理解的修改，且能被审核者验证，每个补丁都应具备独立的合理性。
若某个补丁依赖另一个补丁才能完成完整修改，这是允许的。只需在补丁描述中注明“此补丁依赖补丁X”即可。
将修改拆分为补丁系列时，需特别注意确保系列中的每个补丁应用后，内核都能正常编译和运行。开发者可能会使用 git bisect定位问题，可能会在补丁系列的任意位置中断操作——若你在中间补丁中引入bug，他们会非常不满。
若补丁集无法进一步精简，建议每次仅提交约15个左右的补丁，等待审核和整合后再提交剩余部分。
检查补丁是否存在基本的风格违规问题，详细规则可参阅《Documentation/process/coding-style.rst》。若未进行此项检查，只会浪费审核者的时间，你的补丁很可能会被直接拒绝，甚至不会被阅读。
一个重要例外情况：当将代码从一个文件移至另一个文件时，请勿在移动代码的同一补丁中修改该代码。这样可以清晰区分代码移动操作和你的实际修改，极大方便审核者查看真实差异，并让工具更好地跟踪代码历史。
提交前请使用补丁风格检查工具（scripts/checkpatch.pl）检查补丁。但需注意，该工具仅作为参考，不能替代人工判断。若违规写法让代码更易读，或许可以保留。
检查工具会输出三个级别的结果：
对于补丁中保留的所有违规内容，你必须能够给出合理的解释。
向任何代码提交补丁时，都应抄送对应的子系统维护者和相关邮件列表。可查阅MAINTAINERS文件和源代码修订历史，确定相关维护者。scripts/get_maintainer.pl脚本在这一步非常有用（将补丁路径作为参数传递给该脚本即可）。若无法找到你所操作子系统的维护者，Andrew Morton（邮箱：akpm@linux-foundation.org）可作为最终维护者。
默认情况下，所有补丁都应发送至linux-kernel@vger.kernel.org，但该列表的邮件量极大，许多开发者已设置拒收。请不要向无关列表和人员发送垃圾邮件。
许多内核相关列表托管在kernel.org，可在https://subspace.kernel.org查看完整列表。此外，也有部分内核相关列表托管在其他平台。
Linus Torvalds是所有Linux内核修改的最终裁决者，其邮箱地址为torvalds@linux-foundation.org。他收到的邮件数量极多，目前很少有补丁直接通过他审核——因此通常情况下，应尽量避免向他发送邮件。
若你的补丁修复了可被利用的安全漏洞，请将其发送至security@kernel.org。对于严重漏洞，可能会考虑设置短期保密期，以便发行商向用户推送补丁；在此情况下，显然不应将补丁发送至任何公共列表。更多信息可参阅《Documentation/process/security-bugs.rst》。
修复已发布内核中严重bug的补丁，应通过在补丁的签名区域添加以下内容，定向发送给稳定版维护者（注意：不要作为邮件接收者）：
Cc: stable@vger.kernel.org
除本文档外，你还应阅读《Documentation/process/stable-kernel-rules.rst》。
若修改影响用户态-内核接口，请向MAN-PAGES维护者（见MAINTAINERS文件）发送man-pages补丁，或至少通知相关修改，确保相关信息能更新到手册页中。用户态API修改还应抄送linux-api@vger.kernel.org。
Linus及其他内核开发者需要能够阅读并评论你提交的修改。内核开发者必须能够使用标准邮件工具“引用”你的修改内容，以便对代码的特定部分发表评论——这一点至关重要。
因此，所有补丁都应通过邮件“内嵌”方式提交。最简单的方法是使用 git send-email，这也是强烈推荐的方式。git send-email的交互式教程可在https://git-send-email.io查看。
若你选择不使用 git send-email：
警告：若你选择复制粘贴补丁，请警惕编辑器的自动换行功能破坏补丁格式。
请勿将补丁作为MIME附件发送（无论是否压缩）。许多流行的邮件客户端不会始终将MIME附件作为纯文本传输，导致无法对代码发表评论。此外，MIME附件会增加Linus的处理时间，降低你的修改被采纳的概率。
例外情况：若你的邮件客户端会篡改补丁，可能有人会要求你通过MIME格式重新发送。
有关配置邮件客户端以确保补丁完整发送的提示，可参阅《Documentation/process/email-clients.rst》。
你的补丁几乎肯定会收到审核者的评论，他们会通过回复邮件的方式提出改进建议。你必须回应这些评论——忽视审核者的人也会被他人忽视。你可以直接回复他们的邮件以解答疑问。即使审核意见或问题未导致代码修改，也应添加相应评论或更新变更日志，方便后续审核者理解相关背景。
务必告知审核者你做出了哪些修改，并感谢他们付出的时间。代码审核是一项繁琐且耗时的工作，审核者有时可能会情绪不佳。但即便如此，也应礼貌回应并解决他们指出的问题。发送新版本补丁时，请在封面邮件或单个补丁中添加“补丁变更日志”，说明与上一版本的差异（具体可参阅“标准补丁格式”部分）。将评论过你补丁的人员添加到新版本补丁的抄送列表中，通知他们补丁已更新。
有关邮件客户端推荐和邮件列表礼仪，可参阅《Documentation/process/email-clients.rst》。
Linux内核开发讨论中强烈反对顶部回复（Top-posting）。嵌入式（或“内嵌式”）回复能让对话更易于跟进。更多细节可参阅：https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
邮件列表中经常引用以下内容： A: https://en.wikipedia.org/wiki/Top_post Q: 哪里能找到关于“顶部回复”的信息？ A: 因为它打乱了人们正常阅读文本的顺序。 Q: 为什么顶部回复这么糟糕？ A: 顶部回复。 Q: 邮件中最令人反感的是什么？
同样，请删除回复中所有不相关的引用内容。这能让回复更易查找，同时节省时间和空间。更多细节可参阅：http://daringfireball.net/2007/07/on_top
A: 不应该。 Q: 我应该在回复后保留引用内容吗？
提交修改后，请耐心等待。审核者都很忙碌，可能无法立即处理你的补丁。
过去，补丁常常石沉大海、无人回应，但如今的开发流程已更加顺畅。你通常会在几周内（一般2-3周）收到反馈；若未收到，需确认补丁是否发送至正确的地址。至少等待一周后，再重新提交补丁或提醒审核者——合并窗口等忙碌时期可能需要等待更长时间。
几周后若未收到反馈，可重新发送补丁（或补丁系列），并在主题栏添加“RESEND”字样：
[PATCH Vx RESEND] 子系统/模块：简洁的补丁摘要
注意：若你提交的是修改后的补丁（或补丁系列），请勿添加“RESEND”——该字样仅适用于未做任何修改、完全重复提交的补丁（或补丁系列）。
由于Linus和linux-kernel邮件列表的邮件流量极大，常规做法是在主题栏前缀添加“[PATCH]”。这能让Linus和其他内核开发者更轻松地将补丁与其他邮件讨论区分开。
git send-email会自动为你添加该标识。
为了更好地追踪代码贡献者及其工作内容（尤其是补丁可能经过多层维护者传递后才最终纳入内核的情况），我们引入了补丁的“签署”流程。
签署信息是补丁说明末尾的一行简单文字，用于证明你是该补丁的作者，或有权将其作为开源补丁提交。规则非常简单：若你能确认以下内容：
通过向本项目提交贡献，本人确认：
本人理解并同意，本项目及该贡献均为公开内容，贡献记录（包括本人提交的所有个人信息，含签署信息）将被永久保存，并可根据本项目或相关开源许可证进行再分发。
那么只需添加以下一行文字即可：
Signed-off-by: 随机开发者 <random@developer.example.org>
请使用真实身份（不接受匿名贡献）。若使用 git commit -s命令，会自动为你添加该签署信息。撤销提交（revert）也应包含“Signed-off-by”，git revert -s会自动完成此项操作。
部分人会在末尾添加额外标签，目前这些标签会被忽略，但你可通过这种方式标记公司内部流程或签署相关的特殊细节。
作者签署信息后的其他所有“Signed-off-by”（简称SoB）均来自处理和传递该补丁的人员，他们并未参与补丁的开发。SoB链条应真实反映补丁从贡献者传递到维护者，最终到Linus手中的路径，第一条SoB条目表明该补丁的主要作者身份。
“Signed-off-by:”标签表明签署者参与了补丁的开发，或处于补丁的传递路径中。
若某人未直接参与补丁的编写或处理，但希望表明并记录其对该补丁的认可，可要求在补丁的变更日志中添加“Acked-by:”行。
“Acked-by:”适用于与受影响代码相关或负责该代码的人员。最常见的使用场景是维护者既未参与补丁开发，也未转发该补丁时。
“Acked-by:”也可由其他相关方使用，例如具备领域知识的人员（如被修改代码的原作者）、内核用户态API补丁的用户态审核者或某功能的核心用户。在这些情况下，可选择性地添加“# 后缀”以明确其含义：
Acked-by: 相关方 <stakeholder@example.org> # 作为核心用户
“Acked-by:”的正式程度低于“Signed-off-by:”，仅表明签署者已至少审核过该补丁并表示认可。因此，补丁合并者有时会将审核者的“嗯，看起来没问题”手动转换为“Acked-by:”（但通常最好要求审核者明确给出确认信息）。
“Acked-by:”的正式程度也低于“Reviewed-by:”。例如，维护者可能使用“Acked-by:”表示同意补丁合并，但审核的细致程度可能不及“Reviewed-by:”。同样，核心用户可能未对补丁进行技术审核，但对整体方案、功能或用户界面表示满意。
“Acked-by:”不一定表示对整个补丁的认可。例如，若某个补丁影响多个子系统，某子系统维护者的“Acked-by:”通常仅表示认可该补丁中影响其负责代码的部分。此时需结合实际情况判断，若有疑问，可参考邮件列表归档中的原始讨论。也可使用“# 后缀”明确说明。
若某人有机会对补丁发表评论但未回应，你可选择性地添加“Cc:”标签。该标签用于记录潜在相关方已被纳入讨论。请注意，这是仅有的三个无需获得被提及者明确许可即可使用的标签之一（详见下文“标签使用需获许可”部分）。
“Co-developed-by:”表明该补丁由多名开发者合作创建，用于向联合作者授予署名权（除“From:”标签指定的作者外），适用于多人合作开发单个补丁的场景。由于“Co-developed-by:”表示作者身份，每个“Co-developed-by:”标签后必须紧跟对应的联合作者的“Signed-off-by:”标签。标准签署流程同样适用，即无论作者通过“From:”还是“Co-developed-by:”标签指定，“Signed-off-by:”标签的顺序应尽可能反映补丁的时间开发历程。值得注意的是，最后一个“Signed-off-by:”标签必须是提交补丁的开发者。
注意：若“From:”标签指定的作者与邮件头中“From:”行的人员（及邮箱）一致，则该标签可省略。
示例1：由“From:”指定的作者提交补丁
<变更日志>
Co-developed-by: 第一位联合作者 <first@coauthor.example.org>
Signed-off-by: 第一位联合作者 <first@coauthor.example.org>
Co-developed-by: 第二位联合作者 <second@coauthor.example.org>
Signed-off-by: 第二位联合作者 <second@coauthor.example.org>
Signed-off-by: 原始作者 <from@author.example.org>
示例2：由联合作者提交补丁
From: 原始作者 <from@author.example.org>
<变更日志>
Co-developed-by: 随机联合作者 <random@coauthor.example.org>
Signed-off-by: 随机联合作者 <random@coauthor.example.org>
Signed-off-by: 原始作者 <from@author.example.org>
Co-developed-by: 提交联合作者 <sub@coauthor.example.org>
Signed-off-by: 提交联合作者 <sub@coauthor.example.org>
“Reported-by:”标签用于感谢发现并报告bug的人员，希望能激励他们未来继续提供帮助。该标签仅适用于bug相关，请勿用于感谢功能请求。除非报告无法在网络上获取，否则该标签后应紧跟“Closes:”标签并指向相关报告；若补丁仅修复了报告中部分问题，可使用“Link:”标签替代“Closes:”。请注意，这是仅有的三个无需获得被提及者明确许可即可使用的标签之一（详见下文“标签使用需获许可”部分）。
“Tested-by:”标签表明该补丁已由指定人员在特定环境中测试通过。该标签能让维护者了解补丁的测试情况，便于联系未来的测试人员，并确保测试者获得认可。
“Reviewed-by:”标签则表明该补丁已通过审核，并符合审核者声明的要求：
通过提供“Reviewed-by:”标签，本人声明：
本人已审核该补丁并认为其合理，但除非另有明确说明，否则不保证该补丁能实现其所述目的或在任何特定场景下正常工作。
“Reviewed-by:”标签是一种意见声明，表明该补丁是对内核的适当修改，且不存在未解决的严重技术问题。任何有能力的审核者（完成相关审核工作后）均可为补丁添加该标签。该标签既能认可审核者的工作，也能让维护者了解补丁的审核程度。若“Reviewed-by:”标签来自熟悉相关领域且审核严谨的审核者，通常会提高补丁被纳入内核的概率。
一旦从测试者或审核者处收到“Tested-by:”和“Reviewed-by:”标签，作者在发送下一版本补丁时应将其添加到相应补丁中。但如果下一版本补丁有重大变更，这些标签可能不再适用，应予以删除。通常，删除他人的“Tested-by:”或“Reviewed-by:”标签时，需在补丁变更日志中（“—”分隔符后）注明。
“Suggested-by:”标签用于表明补丁思路来自指定人员，确保其获得相应认可——若我们认真感谢思路提供者，他们未来可能会继续提供帮助。请注意，这是仅有的三个无需获得被提及者明确许可即可使用的标签之一（详见下文“标签使用需获许可”部分）。
“Fixes:”标签表明该补丁修复了之前提交中的某个bug，便于确定问题的起源，助力bug修复审核工作。该标签还能帮助稳定版内核团队判断哪些稳定版内核版本应纳入该修复。这是表明补丁修复bug的首选方式，更多细节可参阅“描述修改”部分。
注意：添加“Fixes:”标签并不意味着可以绕过稳定版内核规则流程，也不能替代向稳定版候选补丁抄送stable@vger.kernel.org的要求。更多信息请阅读《Documentation/process/stable-kernel-rules.rst》。
最后，尽管添加标签是值得鼓励且通常会受到赞赏的行为，但请注意，签署者（即提交者和维护者）可自行决定是否采用这些标签。
在补丁中添加上述标签时需谨慎：除“Cc:”“Reported-by:”和“Suggested-by:”外，其他所有标签均需获得被提及者的明确许可。对于这三个标签，若被提及者已通过lore归档或提交历史使用该姓名和邮箱地址为Linux内核做出贡献，且（对于“Reported-by:”和“Suggested-by:”）相关报告或建议是公开的，则可默认获得使用许可。需注意，bugzilla.kernel.org属于公开平台，但其中的邮箱地址为私有信息——除非该人员在之前的贡献中使用过该邮箱地址，否则请勿在标签中泄露。
本节描述补丁本身的格式要求。请注意，若你的补丁存储在 git仓库中，可使用 git format-patch生成符合标准格式的补丁。但工具无法生成必要的文本内容，因此仍需阅读以下说明。
标准补丁主题栏格式如下：
Subject: [PATCH 001/123] 子系统：摘要描述
标准补丁正文包含以下部分：
diff输出）。主题栏格式能让邮件客户端按主题栏字母顺序排序时，补丁的数字顺序与字母顺序保持一致（因为序号采用零填充格式）。
邮件主题中的“子系统”应明确标识内核中被修改的领域或子系统。
邮件主题中的“摘要描述”应简洁说明该邮件中补丁的内容，不应是文件名。请勿为整个补丁系列（即多个相关补丁组成的有序序列）中的所有补丁使用相同的“摘要描述”。
需注意，邮件的“摘要描述”将成为该补丁的全局唯一标识，会一直保留在 git变更日志中。未来开发者讨论该补丁时可能会引用该描述，人们可能会通过搜索该描述查阅相关讨论。两三个月后，当开发者使用 gitk或 git log --oneline等工具浏览数千个补丁时，可能仅能看到该摘要描述。
因此，摘要描述的长度不得超过70-75个字符，且必须同时说明补丁的修改内容和修改必要性。既要简洁又要详尽，这对撰写高质量的摘要描述来说是一项挑战。
**摘要描述可前缀方括号包含的标签，格式如下：“Subject: [PATCH <标签>...] <摘要描述>”。标签不属于摘要描述的一部分，仅用于说明补丁的处理方式。常见标签包括版本标识（如“v1、v2、v3”，用于响应审核意见而发送的多个补丁版本）或“RFC”（表示请求评论）。**
若补丁系列包含四个补丁，各补丁的编号格式如下：1/4、2/4、3/4、4/4。这能让开发者明确补丁的应用顺序，并确保已审核或应用了系列中的所有补丁。
以下是几个优秀的主题栏示例：
Subject: [PATCH 2/5] ext2: 提升位图搜索的可扩展性
Subject: [PATCH v2 01/27] x86: 修复eflags跟踪问题
Subject: [PATCH v2] 子系统/模块：简洁的补丁摘要
Subject: [PATCH v2 M/N] 子系统/模块：简洁的补丁摘要
“From”行必须是邮件正文的第一行，格式如下：
From: 补丁作者 <author@example.com>
“From”行指定将在永久变更日志中被记为补丁作者的人员。若缺少该 line，将使用邮件头中的“From:”行确定变更日志中的补丁作者。
作者可在“From”行和“Signed-off-by”行中添加组织名称，以表明所属机构或工作赞助方，示例如下：
From: 补丁作者（公司名称） <author@example.com>
说明正文将被纳入永久源代码变更日志，因此对于早已忘记相关讨论细节的资深读者而言，也应清晰易懂。包含补丁所解决问题的症状（如内核日志信息、宕机信息等）尤为重要，便于他人通过搜索提交日志找到适用的补丁。文本描述应足够详细，确保数周、数月甚至数年后，读者仍能通过该描述理解补丁的开发初衷。
若补丁修复了编译错误，无需包含所有编译错误信息——只需提供足够让他人通过搜索找到该补丁的内容即可。与“摘要描述”一样，说明正文也需兼顾简洁性和详尽性。
回溯信息有助于记录导致问题的调用链，但并非所有回溯信息都有价值。例如，早期启动阶段的调用链通常是唯一且明显的。而直接复制完整的dmesg输出会包含时间戳、模块列表、寄存器和栈转储等干扰信息。
因此，最有用的回溯信息应提炼转储中的相关内容，便于聚焦核心问题。以下是一个精简后的优质回溯信息示例：
未检查的MSR访问错误：尝试向0xd51写入0x0000000000000064
在指令指针rIP：0xffffffffae059994（native_write_msr+0x4/0x20）处触发
调用跟踪：
mba_wrmsr
update_domains
rdtgroup_mkdir
“—”分隔行的核心作用是为补丁处理工具标记变更日志的结束位置。
分隔行后的补充注释可用于添加“diffstat”信息，展示修改涉及的文件以及每个文件的插入和删除行数。对于较大的补丁，diffstat尤为有用。若要在“—”分隔行后添加diffstat，请使用 diffstat -p 1 -w 70选项，确保文件名从内核源代码树的根目录开始显示，且不会占用过多水平空间（便于在80列的终端中显示，可能需要适当缩进）。（git默认会生成符合要求的diffstat。）
其他仅与当前时刻或维护者相关、不适合纳入永久变更日志的注释也可放在此处。例如，描述补丁从v1版本到v2版本的变更内容的“补丁变更日志”。
请将此类信息放在分隔变更日志和补丁其余部分的“—”行之后。版本信息不属于将被纳入git树的变更日志内容，仅为审核者提供参考。若将其放在提交标签上方，需要手动删除；若放在分隔行下方，应用补丁时会自动被剥离：
<提交信息>
...
Signed-off-by: 作者 <author@mail>
---
V2 -> V3：移除冗余的辅助函数
V1 -> V2：优化代码风格并响应审核意见
path/to/file | 5+++--
...
有关标准补丁格式的更多细节，可参考以下文档。
手动为补丁添加“In-Reply-To”头部（例如使用 git send-email时）有助于将补丁与之前的相关讨论关联起来，例如将bug修复补丁与对应的bug报告邮件链接。但对于多补丁系列，通常应避免使用“In-Reply-To”链接到系列的早期版本——这样可防止邮件客户端中出现难以管理的多层引用关系。若确实需要添加链接，可在封面邮件文本中使用https://lore.kernel.org/重定向链接指向补丁系列的早期版本。
当其他开发者收到你的补丁并开始审核时，他们必须知道你的工作基于哪个提交/分支——考虑到如今存在大量维护者分支，这一点至关重要。再次提醒，可参考前文提到的MAINTAINERS文件中的T:条目。
这对于自动化CI流程也尤为重要，CI流程会在维护者开始审核前运行一系列测试，以评估提交内容的质量。
若使用 git format-patch生成补丁，可通过 --base选项自动在提交中包含基准树信息。最简便的使用方式是结合主题分支：
$ git checkout -t -b my-topical-branch master
分支'my-topical-branch'已创建并跟踪本地分支'master'。
已切换到新分支'my-topical-branch'
[执行修改和提交操作]
$ git format-patch --base=auto --cover-letter -o outgoing/ master
outgoing/0000-cover-letter.patch
outgoing/0001-首次提交.patch
outgoing/...
打开 outgoing/0000-cover-letter.patch编辑时，会发现底部有“base-commit:”尾部信息，审核者和CI工具可借助该信息正确执行 git am操作，避免冲突：
$ git checkout -b patch-review [基准提交ID]
已切换到新分支'patch-review'
$ git am patches.mbox
应用：首次提交
应用：...
有关该选项的更多信息，可查看 man git-format-patch。
注意：
--base功能从git 2.9.0版本开始引入。
若不使用git生成补丁，仍可添加相同的“base-commit”尾部信息，注明你的工作所基于的提交哈希值。可将其添加到封面邮件或系列中的第一个补丁中，位置放在“—”行下方或所有内容的末尾（紧接你的邮件签名之前）。
确保基准提交来自官方维护者/主线树，而非仅你可访问的内部树——否则该信息将毫无意义。
该流程的许多技术环节可通过b4工具自动化完成，相关文档可在https://b4.docs.kernel.org/en/latest/查看。该工具可帮助跟踪依赖关系、运行checkpatch检查以及格式化和发送邮件。