查看你想提交的子系统

比如这是我们设置的remote:

1
2
3
~/Project/linux bpf-kcsan-obj-memcpy ❯ git remote -v                                                      origin  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch)origin  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push)

实际上这是linus的主树。

因为作者想给bpf子系统提交代码,那我们先把bpf子树拿过来:

1
2
3
4
5
~/Project/linux bpf-kcsan-obj-memcpy ❯ git remote -v       bpf     https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git (fetch)bpf     https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git (push)origin  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch)origin  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push)

之后做rebase(这里就是提醒一下，防止你在linus的master树上开发，但是提交子系统的时候还是要走维护者的子系统的树。)

以下为基本流程:

1
2
准备提交 → 生成邮件补丁 → 发给自己验证 → 邮件发送到维护者和列表→ 公开评审 → 根据意见发 v2/v3 → 维护者收录

安装必须的工具

1
2
3
4
sudo pacman -S --needed \    base-devel git perl \    perl-authen-sasl perl-io-socket-ssl \    b4 sparse python-ply

• • git send-email：发送内核邮件补丁
• • b4：下载、验证、应用邮件列表中的补丁
• • sparse：内核静态检查
• • python-ply：解决 SPDX 检查缺依赖的问题

确认提交身份

1
2
3
4
5
6
7
git config user.name "Quanye Yang"git config user.email "quanyeyang@proton.me"git var GIT_AUTHOR_IDENTgit var GIT_COMMITTER_IDENT

当然是最好使用你的真实姓名啦。

最终检查一下你修改过的文件

检查代码空格，文件末尾新行，缩进，以及代码风格检查:

1
2
3
4
git statusgit diff --checkgit diff | ./scripts/checkpatch.pl --strict --show-types -    # 才写完之后,这样检查一下即可

可以对生成的二进制进行静态检查:

1
2
3
4
5
6
  make C=2 CHECK=sparse lib/rhashtable.o  UPD     include/config/kernel.release  UPD     include/generated/utsrelease.h  CHECK   scripts/mod/empty.c  DESCEND objtool  CHECK   lib/rhashtable.c

可以检查一下上游是否更新过

1
自己检查吧，如果更新了的话就rebase然后重新构建一下

创建commit

这里就和普通github提交是类似的。

但是要写机器规范的commit message:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
rhashtable: use per-init-site lockdep classes for bucket locksAll bucket tables currently share a single lockdep class. This makeslockdep conflate bucket locks from unrelated rhashtable instances.A BPF program attached to lock_release can expose this when pidfsinserts a pid. The tracepoint runs before lockdep removes the pidfsbucket lock from the task's held-lock stack. Deleting an element froma BPF RHASH map then acquires a bucket lock belonging to a differentrhashtable. Since both tables use the same class, lockdep reportspossible recursive locking.Declare a separate bucket lock class key at each rhashtable_init() andrhltable_init() call site, alongside the mutex class key. Store thebucket key in struct rhashtable so tables created during resize keepusing the same class.Fixes: 149212f07856 ("rhashtable: add lockdep tracking to bucket bit-spin-locks.")Reported-by: syzbot+ef8d17bae14efb960935@syzkaller.appspotmail.comCloses: https://syzkaller.appspot.com/bug?extid=ef8d17bae14efb960935Signed-off-by: quanyeyang <quanyemostima@gmail.com>

如果你在这里使用AI的话，也要写上去，我们主打一个诚实守信。

然后检查一把:

1
2
3
git show --checkgit show --statgit log -1 --format=full

生成正式邮件补丁

新手还是建议使用b4,方便又好用，别整有的没的了.

将现有分支纳入 b4 管理

在分支执行:

1
2
cd ~/Project/linuxb4 prep --enroll origin/master    # 以master为基准，把你当前的分支纳入b4的追踪范围之内

然后进行信息的确认:

1
b4 prep --show-info

然后创建密钥:(因为是第一次，之后就不需要了)

Web Endpoint 要求加密签名：

1
patatt genkey

会输出:

1
2
3
[patatt]    signingkey = ed25519:20260801    selector = 20260801

然后配置:

1
2
git config --global patatt.signingkey 'ed25519:实际selector'git config --global patatt.selector '实际selector'

配置 kernel.org Web Endpoint

1
2
git config --global b4.send-endpoint-web \    https://lkml.kernel.org/_b4_submit

由于之前配置过 Gmail SMTP，之后的 b4 命令都显式加：

1
--use-web-endpoint

注册邮箱和签名密钥

1
b4 send --use-web-endpoint --web-auth-new

它会显示：

• • Name
• • Identity：你的 Gmail 地址
• • Selector
• • Public key

确认后，kernel.org 会向你的 Gmail 发一封验证邮件。邮件中会有 challenge token，例如：

1
abcd1234-....

然后进行验证:

1
2
3
b4 send \    --use-web-endpoint \    --web-auth-verify '邮件中的token'

预期就是:

1
Challenge successfully verified

让 b4 检查 patch

1
b4 prep --check

自动生成收件人(最方便的功能):

1
b4 prep --auto-to-cc

然后检查记录信息:

1
b4 prep --show-info

然后再写具体的cover letter,就是描述背景问题之类的，这个就像是github上写PR一样:

1
b4 prep --edit-cover

在没有发布之前，你都可以这样来进行修改.

这好了之后你就可以跑preview看看成品如何:

1
2
3
~/Project/linux fix/lock-tracepoint-bpf-lockdep 41s ❯ b4 prep --format-patch /tmp/previewWriting 1 messages into /tmp/preview  0001-bpf-disable-lockdep-while-running-bpf-on-lock_release.patch

然后使用你的编辑器检查一下patch:

1
~/Project/linux fix/lock-tracepoint-bpf-lockdep ❯ nvim /tmp/preview/0001-bpf-disable-lockdep-while-running-bpf-on-lock_release.patch 

一定要负责任，不要浪费别人的时间。

还有一个问题，就是如果你发的这一版是RFC的话，一定要加上RFC:

1
2
b4 prep --set-prefixes RFC# 发出去会变成 [RFC PATCH] ... 这是标准的做法

然后最后再彩排一下:

1
b4 send --dry-run

先用 reflect 发给自己

这是 b4 专门提供的安全测试模式。邮件头仍显示真实收件人，但 SMTP envelope 只投递给你，不会发给维护者或 syzbot，也不会进入公开归档。

1
2
3
b4 send \    --use-web-endpoint \    --reflect \

--reflect 的保证是：

• • 只有你的 Gmail 真正收到
• • 维护者和列表不会收到
• • 不进入公开邮件归档
• • 分支不会自动升级到 v2

检查收到的邮件

确认：

• • Subject 为 [PATCH] rhashtable: ...
• • From 是你的地址
• • 正文和 diff 完整
• • Reported-by、Closes、Assisted-by、Signed-off-by 都存在
• • b4/patatt 签名显示正常

确认 reflect 成功后，再准备公开发送。公开发送只是去掉 --reflect，但先不要急着执行；届时还需要补充 syzbot、BPF 和相关列表的最终 Cc。

最后去掉reflect,这个流程就相当于走完了。

如何发V2

还是在原来的分支上面。

那么你可以看到:

1
2
3
4
~/Project/linux bpf-kcsan-obj-memcpy ❯ b4 prep --show-revision   v2---  v1: https://patch.msgid.link/20260820-bpf-kcsan-obj-memcpy-v1-1-372c59462268@proton.me

那么这就是准备发v2的状态。