Fu, Wei

Debug Log #3: Stale reads caused by process pausing

Sun, 01 Mar 2026 10:20:45 -0500

今天分享的问题是 Stale reads caused by process pausing，它由 SIG-ETCD Leader Marek Siarkowicz 完成定位并修复。

问题介绍

社区每天都会运行 antithesis 的故障注入测试。整体流程是：先启动一个三节点的 etcd 集群，再启动多个客户端并发执行读写；在读写过程中，antithesis 平台会随机注入短暂故障。待客户端操作结束后，测试会对结果进行数据一致性校验，其中一项关键检查就是 Linearizability - 线性一致性。线性一致性校验方面，社区使用 porcupine 的可视化方法：客户端会记录每一次请求的返回结果，以及请求发出与响应返回的时序，呈现出来的效果如下。

测试会随机暂停某个 etcd 成员进程 2-3 秒（例如通过 cgroup freeze，或对进程发送 SIGSTOP）。问题在于：当原 Leader 暂停恢复后、但尚未意识到已选出新 Leader 之前，它仍可继续处理线性一致性读请求。如上图所示，某客户端已经成功将值更新为 key6=4，并观察到集群的 Revision 为 4；但随后另一个客户端发起读请求时，却读到了 Revision 为 3 的旧数据。这就出现了数据不一致的问题。这种进程停顿在实际场景中还挺常见的，比如底层物理机出现问题需要迁移虚拟机，这种迁移可能会导致短暂的停顿。

ReadIndex

为了实现线性一致性的读操作，etcd 采用 ReadIndex 机制 ( Raft - 6.4 Processing read-only queries more efficiently )：当 Leader 收到线性一致读请求时，它不会直接用本地状态返回，而是先通过一次广播心跳来确认自己仍然是 Leader，从而避免在发生 Leader 变更或网络故障时读到过期数据。

Leader 发起一轮 ReadIndex 流程，向其他节点发送心跳（本质是空的 AppendEntries）。这些心跳会携带一个 Request-ID 作为上下文，用来标识这次 ReadIndex 请求。Follower 不需要解析这个上下文，只需按 Raft 协议正常响应心跳即可。Leader 收到多数派的确认后，就能确定一个安全的 readIndex（对应当时已经被多数派确认的提交进度）。

etcd Leader 在管理 ReadIndex 这件事时，思路其实很直接: 用 Request-ID 作为这次请求的唯一标识，然后按照请求进入流程的先后顺序排队，也就是入队 readIndexQueue。等收到 Follower 回来的心跳响应之后，如果心跳上下文里的 Request-ID 已经拿到了多数派确认，那有意思的地方就来了: etcd Leader 并不是「哪个请求确认了，就只处理哪个请求」。它 advance 函数会从队头开始扫描 readIndexQueue，一直处理到这个 Request-ID 为止。也就是说，一旦某个请求得到确认，那排在它前面的那些请求，它都会可以顺带确认了。

每个 etcd 成员都有一个名为 linearizableReadLoop 的守护协程，用来发起 ReadIndex 请求，从而确认当前最新、已达成共识的 CommitIndex。每次请求的超时大约是 7 秒。除非等待超时，或节点检测到 Leader 发生变化，否则它不会放弃这次请求，而是每隔 500 毫秒使用 同一个 request ID 继续重试。

迟到的双心跳反馈

假设三个成员分别是 etcd0、etcd1、etcd2，当前 Leader 是 etcd0(term=2)。

在停止 etcd0 进程之前，etcd1 收到来自 client1 的线性读请求，于是向 Leader etcd0 发送 ReadIndex(reqID=10)。同时，etcd0 对外发送心跳 Heartbeat(term=2, context=[reqID=10])，紧接着 etcd0 被暂停。

etcd1/etcd2 收到心跳后，分别返回 HeartbeatResp(term=2, context=[reqID=10])。但 etcd1 一直没有等到 etcd0 返回的 MsgReadIndexResp，因此它会继续重试：不断发送同一个 ReadIndex(reqID=10)，直到它发现集群已经出现新 Leader etcd2(term=3)。

由于数据量不大、机器也没死，暂停期间内核仍在收包；再加上暂停时间并不长，etcd0 恢复后仍能收到暂停期间积压的消息：HeartbeatResp(term=2, context=[reqID=10], from=etcd1)、后续重试的 ReadIndex(reqID=10)，以及 HeartbeatResp(term=2, context=[reqID=10], from=etcd2)。可以确定的是：etcd1 的重试 ReadIndex(reqID=10) 一定发生在它发送 HeartbeatResp(term=2, context=[reqID=10], from=etcd1) 之后；但 etcd0 恢复后，协程调度时间不确定，所以不确定 HeartbeatResp(term=2, context=[reqID=10], from=etcd2) 和 ReadIndex(reqID=10) 的顺序。

假设 etcd0 恢复后，又收到了 client2 一个直接发给它自己的线性读请求，那么它会产生新的 ReadIndex(reqID=20)，并向其它两个成员发起新一轮心跳来等待多数派的确认。由于 etcd0 和其它成员之间的连接并没有断开，新一轮心跳的回包在「发生时间」上肯定晚于上一轮 term=2 的回包。如果此时 readIndexQueue 的顺序刚好变成 [reqID=20, reqID=10]，那么当 etcd0 处理到 HeartbeatResp(term=2, context=[reqID=10], from=etcd2) 时，就可能错误地确认队头的 reqID=20。于是 client2 会直接在 etcd0 本地完成线性读；一旦新 Leader etcd2(term=3) 产生新的数据变化，那么 client2 就会读到旧 Revision，从而形成 stale read。

时间	发送方 → 接收方	消息 / 动作	Term	备注
T0	—	etcd0 是 Leader	2	初始状态
T1	client1 → etcd1	线性读触发	2
T2	etcd1 → etcd0	ReadIndex(reqID=10)	2
T3	etcd0 → etcd1/etcd2	Heartbeat(context=[reqID=10])	2
T4	—	etcd0 被暂停 (SIGSTOP / freezer)	2	用户态不处理消息，但内核仍在收包
T5	etcd1/etcd2 → etcd0	HeartbeatResp(context=[reqID=10])	2
T6	etcd1 → etcd0	ReadIndex(reqID=10)	2	重试
T7	etcd2 成为新 Leader	Leader 切换	3
T8	—	etcd0 恢复	2/3
T9	client2 → etcd0	线性读触发	2/3
T10	etcd0 → etcd1/etcd2	Heartbeat(context=[reqID=20])	2/3	为 reqID=20 等待多数派确认
T11	etcd0	处理 Heartbeat(context=[reqID=10],from=etcd1)	2/3
T12	etcd0	处理重复的 ReadIndex(reqID=10,from=etcd1)	2/3
T13	etcd0	处理迟到的 Heartbeat(context=[reqID=10],from=etcd2)	2/3	确认 T10 - ReadIndex(reqID=20) 的请求
T14	etcd0	client2 读本地状态机	2/3	若 etcd2(term3) 有新的数据变化 → stale read

解决的方案就是避免在 linearizableReadLoop 守护协程里使用重复的 Request-ID。

最后

为了避免先入为主，在查看修复代码之前，我会先过一遍测试日志和关键路径源码，先把可能原因收敛到一个大致范围，再回头对照修复方案。

这次排查给我带来灵感的是十年前的一条审阅评论——raft: support safe readonly request。虽然和这次问题不算直接相关，但这确实是调试的乐趣。

最后我在本地用 SIGSTOP 跑了几个小时就把问题复现出来了。这次没有用 AI，不过后续可以整理一个 SKILL，用来更系统地分析这类测试日志。

弗吉尼亚, 2025

Sun, 15 Feb 2026 23:28:45 -0500

弗吉尼亚州北部的小城市待了一年。来这前，我对这个州没有什么概念，唯一的印象就是新闻里，某云服务商又双叒叕在北弗吉尼亚地区出故障了。

北弗吉尼亚的气候和北京差不多，但「妖风」少了些，冬天雨水充足，反倒不干燥。虽然中餐馆屈指可数，但还是有不错的中超，蔬菜调料基本能满足，照着某书的菜谱动手，还是能满足下自己的中国胃。当地超市冰柜里的预制菜不少，仅有限的观察来看，年轻人是消费主力 - 买完回家，「叮」一下就开吃，然后遛狗。这和北京一样的美食荒漠，所以 In-N-Out 什么时候开到这边啊？

在国内，几乎所有事情都能在手机端解决。但在这边，你还是得拿起电话去争取自己的权益，还要接受接通前长达一小时的音乐 - Patience is the key。

美国快递物流没有想象中的差，亚马逊的 Prime 会员几乎能做到「次日达」。但和国内最大的反差是，各个系统的消息推送却是靠实体信件。个人信息泄露比国内更离谱，经常是「你没注意的条款已经替你同意了」，广告保险推销会充斥你的信件箱。即便如此，下楼开信箱依然是我每天的乐趣。

我在远程工作，所以除了去超市买菜之外，平时见到的活人都是在山里 - 好山好水好「无聊」。相较于北京，拿到驾照就可以买车上路了。没有电动车和行人频繁乱穿，对新手司机相对友好。两三小时车程内的徒步路线我大多都走过了。最喜欢的两条线路: 秋天的马里兰州安纳波利斯岩 以及春天前的仙纳度河州立公园。没有西部丰富地貌的震撼，全靠四季交替带来的视觉冲击。对，我说的是北京的百望山公园。

除去文化环境冲击外，AI 的冲击更是无法避免。这段时间，我通过强制让 gpt-5.2-codex 做本地代码检索再做分析，它的代码审阅结果很具有指导价值。再结合最小复现模型去验证思路，很多想法几分钟就能跑通。这种效率，确实会让人短暂地产生「10x 工程师」的错觉。但它和接口报错不同：接口报错通常是显性的，而它的错误往往是「看起来好像挺合理」。它的门槛不在如何调用，而是在判断。

最近看到开源社区里关于「是否接受 AI 代码」的讨论越来越多。但本质上，社区协作仍然是人与人之间的交互。考虑到代码版权与责任边界，即便开发过程用了 AI 辅助，最终提交、签字画押的还是人。其实这个问题很简单，什么时候 AI 能背锅了，什么时候这个话题就停止了。

我还是挺享受在下雨天和朋友一起打暗黑的。

100 天

2025 -> 2026。

Debug Log #2: Using AI to Fix a Flaky Containerd ENXIO Test Case

Tue, 25 Nov 2025 21:20:45 -0500

ENXIO: no such device or address

在 containerd v2.2 发布前期，我们多次遇到与 loop(4) 块设备相关的测试用例 TestLoopbackMount 出现不稳定的问题，但在本地环境却始终无法复现。我在审阅代码时碰到这种失败的频率并不高，重试一下通常就能通过，所以当时并没有太在意。直到最近我连续点了好几次重试之后，我真的不想再当 S(oftware) R(etry) E(ngineer) 了。

=== FAIL: core/mount/manager TestLoopbackMount (0.05s)
    log_hook.go:47: time="2025-10-23T21:49:22.532811960Z" level=debug msg="activating mount" func="manager.(*mountManager).Activate" file="/home/runner/work/containerd/containerd/core/mount/manager/manager.go:134" mounts="[{loop /tmp/TestLoopbackMount989607109/001/fs-1621892597  []} {format/ext4 {{ mount 0 }}  []}]" name=id1 testcase=TestLoopbackMount
    helpers.go:100: unmount /tmp/TestLoopbackMount989607109/001/test-mount-3030342351
    manager_linux_test.go:80:
        	Error Trace:	/home/runner/work/containerd/containerd/core/mount/manager/manager_linux_test.go:80
        	            				/home/runner/work/containerd/containerd/core/mount/manager/manager_linux_test.go:105
        	Error:      	Received unexpected error:
        	            	failed to get loop device info: no such device or address
        	Test:       	TestLoopbackMount

TestLoopbackMount

在真实的生产环境里，基本不会有人用 loop 设备当存储后端。不过在测试环境就不一样了，总不能为了跑几条测试就给 CI runner 挂一块 NVMe 盘吧。containerd 在这里其实只负责 snapshot 的生命周期管理，真正的差异主要来自不同文件系统的实现。所以，用 loop 设备来跑测试已经足够覆盖这部分逻辑，也是最简单直接的方案。

containerd v2.2 将 loop 设备挂载抽象成 mount manager 的插件，挂载流程相对简单：

步骤	操作	说明
1	ioctl(2) + `LOOP_CTL_GET_FREE` 获取 `/dev/loopX`	找到一个可用的 loop 设备
2	`ioctl` + `LOOP_CONFIGURE(后端文件 + LO_FLAGS_AUTOCLEAR)`	绑定文件并设置自动清理标志
3	创建 `/dev/loopX` 的软链接	方便管理，重启后仍能通过软链接找到设备
4	取消 `LO_FLAGS_AUTOCLEAR`	允许 containerd 重启或其他进程重新挂载该设备
5	挂载	将 loop 设备挂载到目标路径
6	取消挂载	卸载 loop 设备
7	打开 `/dev/loopX` 并重新设置 `LO_FLAGS_AUTOCLEAR`	确保设备在关闭句柄后自动释放
8	关闭 `/dev/loopX` 句柄	完成释放流程

第 3、4 步主要用于简化管理，确保 containerd 重启后，loop 设备的后端文件不会被意外清空，同时通过软链接方便找到设备号。

即使多个进程同时通过 LOOP_CTL_GET_FREE 获取相同的可用设备号，内核在绑定后端文件时会加锁，确保只有一个进程成功绑定。其他进程会收到 EBUSY 错误，它们只需重新获取设备号即可。重试逻辑和现有的 losetup(8) 保持一致。

但是在第 7 步，TestLoopbackMount 出现了错误。当它尝试获取设备配置信息时，内核返回了 ENXIO。这个错误表示该设备没有绑定任何后端，因此无法获取状态。

在确认内核锁能够保证不会出现并发问题后，可以断定，错误原因是其他进程调用了 ioctl(LOOP_CLR_FD) 来清理了「错误」设备号。

Using AI?

最直接的方法就是启动一个 Vagrant Box，运行和 CI 环境一模一样的内核版本，然后不停地跑测试；同时写一个小的 eBPF 程序来监控所有的 ioctl 系统调用。只要能复现问题，就可以通过 eBPF 的输出追踪到到底是谁在操作设备。不过准备环境需要做的事情不少：

下载 Ubuntu 22.04 镜像，安装对应的 Azure Ubuntu 版本，以及 llvm、libbpf 等依赖工具，光这些就至少要 20 分钟；
让 AI 写一个监控 ioctl 的 eBPF 程序，简单调试保证没有问题，也至少需要 5-10 分钟。

算下来，整个过程至少也得半小时以上。上周日我在家看 PGL Wallachia S6 - Dota 2 决赛，MOUZ 对雪碧战队，比赛挺精彩的，不想错过 BP 时间，所以就放弃了这个方案。于是，在中间休息的时候，我问了问 AI，看看是不是内部还有其他测试用例在干扰。

好像对了？

根据我过往的经验，如果当甩手掌柜，直接让 AI 去搞定环境跑这种级别的测试，大概率它会迷失在各种奇葩的错误里。加上我也不确定是不是有其他的测试干扰了，我就只是让 Claude Code 去根据我的问题来生成 Plan。

没有意外，第一次的答复永远都是让我改现有逻辑来容忍这个错误。

我通过两次纠正，并把 loop(4) 的内核文档链接发给它后，Claude Code 居然帮我找到了那个干扰项 —— TestAutoclearTrueLoop。

在 TestAutoclearTrueLoop 测试里，只要把设备句柄关闭，内核就会自动解除设备背后的后端文件，不需要手动调用 LOOP_CLR_FD。由于多个进程同时申请设备，假设当 TestAutoclearTrueLoop 通过关闭句柄释放了设备 X 后，其他进程就可以获取到这个设备 X。如果此时 TestAutoclearTrueLoop 再调用 LOOP_CLR_FD 去释放这个设备，就可能会影响到其他进程的操作。

不过，Claude Code 的分析有点离谱。我倒是挺好奇，它到底是以什么概率「选出」这段既胡扯又好像有点道理的分析的。

最终花费了我 5 分钟 - 3.4k tokens，还不错，没有影响看比赛。

Previewing new mount manager in containerd v2.2.0

Sun, 02 Nov 2025 10:20:45 -0500

延续上一篇文章，在 v2.2.0 版本中最关键的更新是 Mount Manager 的引入。该功能主要用于简化现有 snapshotter 的管理方式，并为后续用户自定义的存储方案提供更灵活的集成能力。在深入介绍之前，我们先回顾一下 snapshotter 在演进过程中存在的问题。

Mount by Snapshotter ?

最初，snapshotter 的接口设计仅负责管理 snapshot 的生命周期；至于 snapshot 的挂载（mount）动作，则由上层组件自行处理，例如镜像解压插件（diff）或 containerd-shim。该设计的前提是假设 snapshotter 的存储行为足够简单，挂载逻辑完全可以依赖底层文件系统的能力，例如 OverlayFS 的 union mounting 特性。

From 2017: containerd deep dive presentation at the containerd summit

然而，这一设计基于的前提过于理想化，忽略了更复杂的使用场景，例如文件系统镜像的初始化、底层块设备的动态添加或移除，以及多阶段的挂载流程。真正暴露设计局限的是延迟加载（lazy loading）技术的引入，其次是安全容器（VM-like container）对挂载的需求。

[v1.4.0] Skip the Prepare phase with a two-stage commit

延迟加载镜像不需要在本地下载完整的镜像层数据，通常只依赖索引信息即可，例如 nydus、overlayBD 或 stargz。为了让 containerd 在延迟加载场景中避免下载原始镜像层数据，snapshotter 采用了两项约定:

所有以 containerd.io/snapshot/ 开头的用户自定义标签会被透传到 snapshotter.Prepare 接口。snapshotter 可借助这些标签获取镜像相关信息（具体取决于各自的存储方案）。这些信息可以在镜像构建阶段就写入 OCI 镜像的元数据中，containerd 会自动识别并传递。
在 Prepare 阶段，containerd 会传递标签 containerd.io/snapshot.ref=chainID。如果自定义 snapshotter 使用延迟加载技术，它可以利用这些标签获取镜像索引数据并完成初始化。此时，snapshotter 应在 Prepare 阶段直接将 snapshot 提交为 Committed 状态，并返回 ErrAlreadyExists，让 containerd 认为该层已准备就绪，然后继续处理下一个镜像层。

在第二个约定中，自定义 snapshotter 可能会发起 HTTP 或 RPC 请求，从而导致 Prepare 调用耗时较长。而 containerd 底层的元数据存储（metadata plugin）依赖 boltdb，这是一种仅支持单写操作的嵌入式数据库。由于 snapshot 元数据同时由元数据存储和 snapshotter 的双重 boltdb 管理，为避免单个大锁阻塞其他操作，containerd 将 Prepare 阶段的数据提交设计为两步式流程。

NOTE: 使用双 boltdb 管理的一个好处是，GC 扫描可以以异步方式清理 snapshot，从而避免阻塞其他操作。

与 OverlayFS snapshotter 不同，延迟加载类存储必须在 Prepare 阶段提前完成容器根目录挂载所需的初始化。例如，stargz-snapshotter 会在这一阶段启动 FUSE 挂载，而 overlayBD 则通过 TCMU 初始化 iSCSI 块设备。由于 containerd 在容器启动前只会调用一次 Prepare 来创建可写层，snapshotter 只能利用这个唯一窗口完成初始化 —— 这实际上形成了文档未明确说明的 「隐含的第三个约定」 。

但随之出现了新的问题：这些初始化过程中创建的挂载点或设备，应在何时安全清理？

容器根目录的最终挂载和清理都由 containerd-shim 完成，而 snapshotter 仅会在 snapshot 被删除时才执行清理。这意味着挂载点或设备可能在容器退出后仍被保留，从而导致清理滞后，甚至引起额外的系统资源占用。

[2022] Add new ExtraOptions field?

同样，安全容器在启动前也需要执行额外的初始化步骤，仅依靠现有的 snapshotter 接口无法优雅地实现优化。曾经，Kata Containers 社区提出通过 ExtraOptions 将配置信息传递给 Kata-container-shim，但最终被否决。原因很明确：在容器启动前，不仅 containerd-shim 会挂载容器根目录，CRI 插件也需要挂载它以获取进程的 UID/GID。一旦 containerd 无法识别或理解 ExtraOptions，这套方案就无法成立。此外，ExtraOptions 本身也无法表达复杂的初始化逻辑，因此无法满足需求。

NOTE: ExtraOptions 需求来源于机密计算 - https://github.com/confidential-containers/confidential-containers/issues/137

[2023] mount.helper binary?

在 Darwin 支持开发阶段，Akihiro Suda 曾提出利用 mount.helper in – Add support for bind-mounts on Darwin (a.k.a. “make native snapshotter work”) 扩展挂载方式，类似 mount.fuse，用于满足第三方挂载需求。虽然该方案解决了「如何执行挂载」的问题，但 mount 本身只是一个代码库而非插件服务，并且没有处理挂载点生命周期管理，因此 snapshotter 的核心问题仍然没有解决。

[v2.1.0] EROFS snapshotter

直到上一个版本，新的 EROFS 存储支持还是在 Prepare 阶段挂载 loopback 设备。

Mount Manager

Derek 在今年年初提出了 Mount Manager 插件。其核心理念是将挂载初始化操作从 snapshotter 中解耦。通过这一插件机制，挂载点的初始化由 Activate 操作负责完成，而不再依赖 snapshotter 的 Prepare 阶段。同时，Mount Manager 可以将挂载点的生命周期与其他资源建立引用关系。例如，将挂载点与容器生命周期绑定：当容器退出并被删除时，containerd 的 GC 模块会沿着引用关系自动清理不再需要的挂载点。

type Manager interface {
	Activate(context.Context, string, []Mount, ...ActivateOpt) (ActivationInfo, error)
	Deactivate(context.Context, string) error
	Info(context.Context, string) (ActivationInfo, error)
	Update(context.Context, ActivationInfo, ...string) (ActivationInfo, error)
	List(context.Context, ...string) ([]ActivationInfo, error)
}

NOTE: containerd GC 设计可查看 - https://fuweid.com/post/2023-containerd-17-gc/.

Activate 会将 snapshotter 管理的挂载信息转换为可以直接用于系统调用的挂载描述。为了支持更灵活的扩展能力，Mount Manager 引入了 Mount Handler 和 Transformer 插件机制。原则上，自定义存储方案只需定义不同的 mount.Type，便可实现独立的挂载初始化逻辑。

举个例子，如下图所示。 Activate 会完成以下三步：

初始化一个 500 MiB XFS 镜像。
创建一个 loopback 设备，将其绑定到第一步创建的镜像上，并完成挂载。
在第二步挂载的基础上，创建 upper 和 worker 目录，并返回一个 OverlayFS 挂载信息。

内置的 Mount Handler 和 Transformer 通过 Go Template 实现链式初始化过程中信息的共享。引入的概念较多，有兴趣的朋友可以参考文档：mounts.md。

New intergration >= v2.3.0

v2.2.0 版本仅引入了 Mount Manager，目前只有 EROFS snapshotter 集成了这一方案（它现在不再在 snapshotter 内部处理任何挂载操作）。此外，Mount Manager 还未开放 Mount Handler 插件 (proxy) 接口，第三方组件的调用方式计划在下一版本中引入。

可以预见，未来 snapshotter 将更多聚焦于元数据管理，逐步回归其最初的设计定位。而 Mount Manager 则可能成为存储管理的新趋势——它将更加贴近容器运行时，尤其在安全容器的设计中，其作用会愈发明显。

NOTE

Mount Manager 的运行同样依赖 boltdb 来管理状态，但要求该数据库运行在 tmpfs 上。如果有人将 containerd 的 state 目录配置在持久化存储中，containerd 初始化时将会失败。通常，社区建议将 state 目录（临时数据）放置在 /run 等 tmpfs 路径下。

Previewing Rebase Snapshots in containerd v2.2.0

Fri, 31 Oct 2025 19:20:45 -0500

containerd 社区近期发布了 v2.2.0-rc.0 版本，预计将在亚特兰大 KubeCon 前正式 GA。在正式发布之前，我想先分享其中的一个特性 – Rebase Snapshot，它可以显著提升大型镜像的下载效率。

Snapshot Model

在 Open Container Initiative (OCI) 镜像标准中，每次对容器镜像的修改都会生成一个镜像层（Image Layer）。每层只包含新增、删除或修改的文件，层与层之间互相依赖，就像 Git 的提交记录一样，后一层是基于前一层构建的。

容器运行时（消费端）会按照依赖顺序依次应用（或叠加）这些镜像层的数据，最终组合形成容器进程的根文件系统。至于数据如何叠加和存储，则取决于所采用的底层存储。此外，容器进程对其根文件系统产生的变更，可以被「提交」并封装为一个新的镜像层，这是常见的镜像构建方式。

为了统一管理镜像层和容器文件系统的数据，containerd 引入了 snapshot的概念。它将这些文件系统抽象为可管理的 snapshot，并使用统一的 snapshotter 接口来对接和表达不同底层存储介质（如 OverlayFS, EROFS, OverlayBD, DevMapper 等）的实现方式。

NOTE: From 2017: containerd deep dive presentation at the containerd summit

Snapshot 包含两个关键状态：

* Active：在此状态下，允许对文件内容进行添加、删除和修改等操作。

* Committed：一旦 Active Snapshot 被提交（Commit），它将转换为 Committed 状态。
            原则上，处于 Committed 状态的文件内容是不可变更的。

在解压镜像层数据时，containerd 会基于上一层 snapshot 来创建新的 active snapshot。上一层 snapshot 可以为空，「通常」表达当前 active snapshot 对应着第一层。解压数据完毕后，再将其提交成 committed 状态；重复此流程直到所有镜像层都处理完毕。Snapshot 之间的依赖关系能帮助 containerd 的 GC 模块识别哪些 snapshot 已经不再被引用（orphan snapshot），从而将其安全删除。但这也意味着 containerd 必须按照顺序解压镜像。

Existing Enhancements on pulling

[v1.0.0] Initial Version

在 containerd 的最初版本（2017 年）中，镜像处理流程被设计为两个阶段：首先并发下载所有镜像层，然后按照层级关系依次解压。解压某一层时，containerd 需要先将其所有祖先 snapshot 按顺序进行 union mount，形成完整的基础视图，然后才能在此基础上应用当前层的数据。

[v1.3.0] Direct unpack support for overlayFS

Union mount 本身是一项开销较高的操作，特别是在执行卸载（umount）时更为明显。在 Linux kernel v5.10（支持 volatile 选项）之前，卸载 OverlayFS 挂载点会触发强制刷盘，写放大进一步增大了开销。而实际上，在解压 OCI 镜像层数据时，并不需要访问上一层已展开的文件内容；containerd 也无需先构建完整的文件系统视图再进行解压。

因此，从 v1.3 开始，containerd 为 overlayFS snapshotter 引入了一种优化方式：直接将镜像层解压到对应的 snapshot 目录，避免为了解压而执行 union mount。

[v1.3.0] Add simultaneous unpack support

此外，v1.3 版本实施了另一项优化：下载与解压的并行处理。containerd 现在无需等待所有镜像层下载完毕，而是在任何一层下载完成后就立即启动解压任务，以提升镜像处理的整体速度。然而，这项优化存在一个关键的局限性：镜像层的解压必须严格按照其依赖的顺序进行。这意味着即使后面的层（例如第 3 层）比前面的层（例如第 2 层）先下载完成，它也必须等待所有前置层（第 1 层、第 2 层等）下载并解压完成后才能开始处理。由于在大多数镜像结构中，较小或变更较少的层通常位于镜像的末尾，因此顺序依赖使得「并行解压」收益有限。

[v2.1.0] Multipart layer fetch

在上一个版本中，containerd 引入了同一镜像层的并发下载能力。利用 OCI Distribution 协议中支持可断点续传 - resumable pull - 的特性，containerd 会将大型镜像层切分为多个区段，多路并发下载。各区段数据在内存中按顺序重新组合，并最终写回本地磁盘，形成完整的镜像层。这一优化提升了大镜像层的下载速度，但也带来了两个限制：

* 会额外占用内存，因为数据区段需要在内存中进行拼接；

* 效果依赖区段大小配置，划分不合理会影响性能收益。

目前，大多数由 Go 编写的服务（包括容器镜像仓库）默认使用 HTTP/2 协议。然而，HTTP/2 在传输大体积数据时效率并不高，带宽利用率受限，服务端往往需要等待客户端的窗口更新（WINDOW_UPDATE），而非持续传输数据。containerd 通过多连接并发下载来缓解这一问题，本质上是在规避 HTTP/2 流控带来的性能限制。在网络质量可控的情况下，使用单连接的 HTTP/1.1 反而可能实现更高的吞吐性能。

Rebase

尽管过去的优化提升了下载效率，但一个事实没有改变：镜像层的解压仍然是按顺序进行的。为了解决这一瓶颈，Derek 在问题 Parallel Container Layer Unpacking 中提出了 Rebase Snapshot 来加速处理。

经常使用「变基」的朋友对这个词应该不陌生：在 Git 中，git rebase upstream/master 可以用来更新当前分支。它的本质是将当前分支上的提交，在最新的 master 分支基础上重新回放一遍。

NOTE: From https://git-scm.com/book/ms/v2/Git-Branching-Rebasing

同样地，支持 rebase 的 snapshotter 允许在提交时，将一个没有 parent 的 active snapshot 绑定到指定的 committed snapshot 上，如下图所示。

在下载镜像时，containerd 会同步解压所有镜像层，此时这些 Active snapshot 尚未指定父 snapshot。解压完成后，它们会按顺序提交，并关联到指定的父 snapshot，从而建立层之间的依赖关系。这个过程类似于 Git 的 rebase：在管理层面回放各层提交，实现了真正意义上的「同步解压」。

我在本地开发机器上测试了镜像 huggingface/transformers-pytorch-gpu:4.41.2（解压后约 17.7 GiB）的下载与解压效果，并与 containerd v2.1.4 版本进行了对比。

本地机器配置如下：

为了避免网络带宽的影响，我把镜像下载到本地，并传到本地运行的 registry 服务里。优化效果还是挺明显，一倍左右。

v2.1.4 需要 - 72s

关闭 multipart layer fetch 优化

max_concurrent_download = 3

v2.2.0-rc.0 需要 - 34.7s

关闭 multipart layer fetch 优化

max_concurrent_download = 3

Max_concurrent_unpacks = 3

Debug Log #1: From Containerd -EBUSY to ETCD bbolt Corruption

Sun, 21 Sep 2025 09:20:45 -0500

我打算开一个 Debug Log 系列，把平时在开源项目或生产环境里遇到的有趣问题记录下来。作为系列的第一篇，我想分享近期的两次排查经历：一次是 Containerd 临时挂载点残留，另一次是 ETCD 数据库损坏。

-EBUSY 导致临时挂载点残留

Netflix 工程师 halaney 在 Containerd 社区提交了一个问题 #12139：他们在测试环境中遇到了大量的 Idmappings 临时挂载点残留问题，几乎在并发创建容器时必现。据了解，Netflix 计划升级到 Containerd v2.0.x，这个问题成为了升级的障碍。他们内部已经通过使用 MNT_DETACH - lazy umount 的方式来规避。不过，我个人并不喜欢这种做法，因为它并没有真正解决问题本身。

前几年，我曾遇到一个「黑科技」日志采集方案——它会扫描 /run/containerd 目录下的挂载点，也就是容器的根目录，并长期持有容器根目录下的日志文件句柄，导致出现 -EBUSY 错误而无法清理容器挂载点，从而出现残留。业务为重，只能妥协，加上 MNT_DETACH :)。过往社区也出现过类似问题，但最终发现都是安全软件间歇性扫描导致的。因此一开始排查这个残留问题时，我会下意识地认为这可能是「环境」问题。

我当时怀疑的对象是 systemd.mount。每当 host mount_namespace 出现新的挂载点时，systemd 就会生成一个 mount.unit。比如当你运行 docker run -d busybox sleep 1d 时，你会发现会有一个这样奇葩的 mount.unit。老实说，我并不知道这东西的实际作用 :)

$ sudo systemctl list-units | grep var-lib-docker
  var-lib-docker-overlay2-9643eb3cca86f8de7ac881124eb01ce10d3af44872f246e196a1cfe9e0ec6753-merged.mount loaded active     mounted      /var/lib/docker/overlay2/9643eb3cca86f8de7ac881124eb01ce10d3af44872f246e196a1cfe9e0ec6753/merged

$ sudo systemctl status var-lib-docker-overlay2-9643eb3cca86f8de7ac881124eb01ce10d3af44872f246e196a1cfe9e0ec6753-merged.mount

● var-lib-docker-overlay2-9643eb3cca86f8de7ac881124eb01ce10d3af44872f246e196a1cfe9e0ec6753-merged.mount - /var/lib/docker/overlay2/9643eb3cca86f8de7ac881124eb01ce10d3af44872f246e196a1cfe9e0ec6753/merged
     Loaded: loaded (/proc/self/mountinfo)
     Active: active (mounted) since Sat 2025-09-20 22:51:06 EDT; 6min ago
      Where: /var/lib/docker/overlay2/9643eb3cca86f8de7ac881124eb01ce10d3af44872f246e196a1cfe9e0ec6753/merged
       What: overlay

通过 opensnoop-bpfcc 和 bpftrace 等工具观察各种可能的系统调用，但 systemd.mount_process_proc_self_mountinfo 只是读取了 /proc/self/mountinfo，并不是问题的根源。后来我又花了不少时间研究 runc 相关逻辑，发现 runc 做了很多保护性处理，确保挂载点传播不会引发问题。最后只能回过头来看 Containerd 的代码了。

从 retsnoop 的结果来看，mnt_get_count 在 propagate_mount_busy 函数中返回了多个引用（如下图所示），这很可能是因为多个文件句柄同时指向了同一个挂载点。结合此前的观察，可以排除外部进程扫描的可能性，因此这些额外引用几乎只能来源于子进程创建过程。

IDmapping 是在挂载点上建立一个 UID/GID 映射层，使同一份数据在不同目录下呈现不同的所有者身份，具体细节可以查阅 containerd 1.7: UserNamespace Stateless Pod。IDmapping 的挂载流程如下：

Step 1：通过 open_tree(2) 复制一份源目录的挂载子树，并获得一个指向该子树的文件句柄。
Step 2：通过 mount_setattr(2) 系统调用修改挂载子树的属性。主要利用 user_namespace 引用来调整 UID/GID 映射。
- 例如，源目录所有者是 root，我们可以映射成用户 1000。
Step 3：通过 move_mount(2) 系统调用将挂载子树移动到目标目录，这时挂载点形成。
Step 4：关闭文件句柄。

在第三步成功返回后，该文件句柄会指向目标目录（即挂载点）。因此，在关闭前，它可能被复制到子进程中，例如通过 clone(2) 系统调用。即使 Containerd 在第一步中使用了 OPEN_TREE_CLOEXEC，在执行 execve(2) 之前，子进程仍会持有挂载点的句柄。如果这时调用 umount，就会触发 EBUSY 错误。

此外，第二步需要 Containerd 通过一次 ptrace re-exec 获取 user_namespace 引用。这意味着在并发创建容器时，目标挂载点的文件句柄很容易被复制到 Containerd 的子进程中。当然，调用二进制 CNI 以及启动 contained-shim 同样也会触发复制行为。因此，mnt_get_count 返回高引用数也就可以理解了。由于 open_tree(2) 在挂载时必须生成文件句柄，这一问题基本无法避免。最终的解决方案只能依靠多次重试，毕竟 clone(2) 与 execve(2) 之间的时间窗口相对较小。后续可以通过 mount plugin 统一管理所有挂载点，并借助 GC 机制从根本上解决残留问题。

在这里，我强烈推荐使用 retsnoop 来排查 Linux 内核中的系统调用错误。即便不是内核开发者，也可以通过全局检索 Linux 源代码，并结合 retsnoop 提供的调用栈信息，高效地进行定位与分析。

panic: assertion failed: Page expected to be: 5

ETCD 社区最近将故障注入测试迁移到了 antithesis 产品上。该产品会在测试运行过程中随机注入网络丢包、网络连通性中断以及 CPU 限流等故障。文档中并未说明具体实现方式，但由于 ETCD 测试基于 docker-compose，最直观的 CPU 限流手段就是通过 cgroup 来完成。

在迁移过程中发现，ETCD Member 会接收到损坏的 snapshot（见 #20271），如下输出所示。这表明 bbolt 存储结构中出现了错误的引用。ETCD 社区过去也曾遇到过许多类似的数据库损坏问题，其中大多数由断电引起。由于对 antithesis 环境缺乏深入了解，起初很容易将其误认为是网络故障导致的错误。

panic: assertion failed: Page expected to be: 5, but self identifies as 0
goroutine 8052 [running]:
go.etcd.io/bbolt/internal/common.Assert(...)
	go.etcd.io/bbolt@v1.4.2/internal/common/verify.go:65
go.etcd.io/bbolt/internal/common.(*Page).FastCheck(0x7f16ce802000, 0x5)
	go.etcd.io/bbolt@v1.4.2/internal/common/page.go:83 +0x1d9
go.etcd.io/bbolt.(*Tx).page(0xc0010a31d0?, 0xc0002992e8?)
	go.etcd.io/bbolt@v1.4.2/tx.go:598 +0x7b
go.etcd.io/bbolt.(*Tx).forEachPageInternal(0xc000c71340, {0xc0010a31d0, 0x1, 0xa}, 0xc0002993a0)

该测试过程主要通过注入网络故障和 CPU 限流来触发 Follower 节点落后于 Leader 日志进度的情况。随后，Leader 会发送完整数据库快照（snapshot）以完成同步。除此之外，测试还会以高频率对所有 Member 进行 defragment 操作。

这个问题已经放置一段时间，没有太大进展，因为大家普遍认为是环境问题。后来抱着试一试的心态去查看 ETCD Member 日志。只能说这种方法比较「原始」，一旦日志记录不够详尽，没有关键的信息，就几乎是在浪费时间。只能说运气还不错，大部分 debug 信息都输出了。

Follower 收到的数据库快照显示 Index 为 74，并且确认已落盘。然而，当该 Follower 从该快照恢复时，却显示 Index 为 67。由此可以确认，这不是环境问题，而是 ETCD 内部存在 Race condition。

这个 race condition 是由 defragment 操作触发的。在 ETCD 使用接收的快照之前，它会通过 rename(2) 覆盖当前正在使用的数据库文件。事件时间线如下：

需要解释的是：如果一个进程保持着一个文件句柄，即使这个文件被删除或覆盖，该进程依然可以继续通过这个句柄操作文件。一个最直观的场景是：业务进程写了大量日志，而磁盘空间几乎耗尽，此时需要清理日志文件，但业务进程不能重启。如果直接删除日志文件，文件并不会真正释放空间，因为业务进程仍然持有文件句柄，可以继续写入数据。正确的做法是使用 truncate(1) - truncate -s 0 log 或者是 cat /dev/null > log，保留原文件的 inode，将文件大小强制清零，从而释放磁盘空间，同时保证业务进程继续写入日志而不受影响。

同样地，在 T10 之后，ETCD Member 会将后续的变化写入到一个已经被覆盖的文件中。到这一步，其实问题不大——重启后的 ETCD Member 仍然落后于其他 Member，仍可以继续接收新的快照。然而，从 T10 之后，它开始成为 Leader。在测试的后期，它需要向其他 Member 发送快照，这时问题就暴露出来了。

在发送快照时，ETCD 利用了多版本并行控制 (MVCC) 特性，只会发送当前 bbolt 只读事务对应的版本。bbolt 数据库的前两页保存着整棵 B+Tree 的根节点引用，因此在发送快照前，ETCD 会先发送当前事务版本的根节点引用，然后再读取数据库的其余部分。即使在此过程中有新的事务提交，也不会影响当前版本的数据，从而保证快照的一致性，如下图所示。这里有一个前提，文件不能被覆盖。

在测试过程中，ETCD 的 snap.db 文件已经被 T8 时刻的操作覆盖，其内容与正在使用的、已被删除的文件完全不同。值得注意的是，bbolt.WriteTo 并没有使用原有的文件句柄，而是重新打开了一个新的句柄。由于前两页存储的根节点引用与实际存储内容不一致，最终会导致 bbolt 初始化失败并触发 panic。

为解决该问题，ETCD 需要避免 Race Condition（见 #20553），而 bbolt 则必须确保传输的文件内容保持一致（见 #1057）。不过，对于 #1057，实际上也可以考虑重新打开一份已被删除文件的句柄，因为 io.Copy 可以利用 splice(2) 实现 Zero-Copy。当然，在 ETCD 发送快照时，中间存在一层 Copy，此时无法使用 splice(2)，因此使用 pread(2) 也还行吧。

diff --git a/tx.go b/tx.go
index f32a209..d6c2e85 100644
--- a/tx.go
+++ b/tx.go
@@ -5,8 +5,10 @@ import (
        "fmt"
        "io"
        "os"
+       "path/filepath"
        "runtime"
        "sort"
+       "strconv"
        "strings"
        "sync/atomic"
        "time"
@@ -390,7 +392,7 @@ func (tx *Tx) Copy(w io.Writer) error {
 // If err == nil then exactly tx.Size() bytes will be written into the writer.
 func (tx *Tx) WriteTo(w io.Writer) (n int64, err error) {
        // Attempt to open reader with WriteFlag
-       f, err := tx.db.openFile(tx.db.path, os.O_RDONLY|tx.WriteFlag, 0)
+       f, err := tx.db.openFile(filepath.Join("/proc", strconv.Itoa(os.Getpid()), "fd", strconv.Itoa(int(tx.db.file.Fd()))), os.O_RDONLY|tx.WriteFlag, 0)
        if err != nil {
                return 0, err
        }

最后

我尝试用 AI 来排查这两个问题，但可能是使用方式不对。即使输入了大量信息，把我的分析步骤都写了出来，依然得不到理想的结果。最接近的一次是，它认为我没有关闭 open_tree(2) 返回的句柄，于是它在代码里加了一行关闭操作。结果却导致对同一个句柄进行了两次关闭，最后它又开始聚焦在为什么会发生新的错误…

Streaming JSON/Protobuf in Kubernetes

Mon, 03 Feb 2025 10:20:45 -0500

OOM-KILL

当 kube-apiserver 处理 LIST 请求时，它会一次性将数据序列化为 JSON 或 Protobuf 格式，然后交由底层的 Go/http 处理。根据标准的 encoding/json 库实现，kube-apiserver 需要分配一大块内存来存放完整的序列化结果。更严重的是，这块内存要等到数据的最后一个字节被传输完毕后才会释放，容易导致高峰时的内存占用激增。

在 Go/http2 实现中，每个 http2/stream 都有一个传输队列，队列中的成员存储需要发送的数据。多个 http2/stream 共享同一个 TCP 连接，为了保证公平性，Go 按顺序选择 http2/stream 并限制每次发送的数据量。由于每个 http2/stream 只有有限的发送窗口，数据会像“挤牙膏”一样逐步推送。然而，在 kube-apiserver 的实现中，每个 http2/stream 的传输队列通常只有一个成员指向序列化的数据，该成员会一直持有完整的序列化数据，直到传输完毕才释放。如果短时间内有多个大请求，kube-apiserver 会迅速消耗大量内存，甚至可能导致 OOM 崩溃。

更揪心的是 encoding/json 的实现。虽然它内部使用了 sync.Pool 来提高内存复用率，但这也带来了一个隐患：如果先处理了少量的大请求，而后续主要是大量的小请求，那么 sync.Pool 可能会长期持有之前分配的大块内存，而这些内存无法及时释放。在这种情况下，kube-apiserver 的内存占用无法真实反映当前的请求负载，即使大请求已经结束，进程仍可能维持较高的内存使用率。– Kubernetes#114276

KEP-5116

解决这个问题的关键在于引入 流式处理 来序列化数据。KEP-5116 根据 LIST 响应的结构特点，可以依次序列化 TypeMeta、ListMeta，然后逐项序列化 Items，避免一次性分配和持有大块内存，从而降低内存占用。

type XYZList struct {
        metav1.TypeMeta `json:",inline"`
        // Standard list metadata.
        // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
        // +optional
        metav1.ListMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

        // List of XYZ.
        // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md
        Items []XYZ `json:"items" protobuf:"bytes,2,rep,name=items"`
}

这样不仅解决了 encoding/json 大内存回收的问题，还解决了 Go/http2 的内存管理问题。在流式处理的模式下，http2 stream 的队列成员数量会增加，但每个成员最多只会引用 1-2 MiB 的内存，并在发送完毕后及时释放。此外，根据 Go/http2 的实现，当网络较为繁忙时，kube-apiserver 无法无限制地向 http2/stream 队列中添加待发送的数据成员，从而在一定程度上抑制了内存的过快增长，进一步提升了系统的稳定性。

Benchmark

实验准备:

1024 个 configmap，每个 configmap 大小为 1 MiB
每个请求数据量为 100 MiB, 数据格式为 JSON，请求不经过 ETCD
每秒最多发出 10 个请求，客户端最多并发处理 100 个请求
一共发出 6000 个请求

下图左侧的为 kube-apiserver v1.32.0 版本，它最高消耗了将近 29 GiB; 而采用了 Kubernetes#129334 的版本仅仅需要 2-3 GiB，内存占用大幅降低。这个优化方案比 WatchList 实用性更强，客户端不需要做任何改造。可惜这么好的优化，上游不愿意 backport 到老版本上。

65K Nodes?

Kubernetes 在近几个版本的优化都挺给力的，比如 v1.31 ConsistentListFromCache 可以很大程度避免击穿背后的 ETCD，再配合上基于缓存的分页能力，ETCD 仅需要做好数据推送的任务就好了。最后再配合上 KEP-5116，65K 节点不是梦啊 :)

NOTE: 这个问题同样存在于 gRPC-go 的 UnaryCall 方式中。除非服务端一开始就采用 gRPC-go StreamCall 进行流式传输，否则在处理大规模数据时，仍然可能触发 OOM-KILL。ETCD 也面临类似的挑战，但 Kubernetes 目前的优化策略更倾向于让 ETCD 专注于数据推送，而由 kube-apiserver 承担数据处理的压力。从这个角度来看，Kubernetes 也算是间接解决了这个问题。

退群「Hall of shame」

Tue, 03 Sep 2024 07:47:45 +0800

在 GO 1.23 版本中，GO Linker 将来会限制 //go:linkname 直接引用标准库中不可访问的对象。看到这个消息后，我立刻用 GO 1.23.0 编译了 containerd，发现即使不加 -checklinkname=0 也能正常工作。之前为了支持 ID-mapped mount, 我在 containerd 项目里使用了 GO runtime 的隐藏功能，算是语言层面的灵活运用。现在可倒好，GO 团队直接在代码里把 containerd 列为 Hall of shame 成员。这种强行拉入群的形式实在无力吐槽，只能想想如何退群了。

为什么要使用 go:linkname

Kubernetes 社区之所以能落地 User Namespace 特性，是因为 Linux 社区在 2022 年引入了 ID-mapped mount 的概念。原先，文件属性中的 UID 和 GID 是固定的，只有特定的用户或用户组才能访问相应的文件。容器镜像中的文件大多是由 root 用户创建的，如果要让非特权用户访问镜像中的所有内容，过去唯一的办法是使用 chown -R 来物理改变所有文件的 UID 和 GID。

Image	Size	Inodes	overlayfs w/ metacopy	overlayfs w/o metacopy
tensorflow/tensorflow:latest	1489MiB	32596	1.29s	54.80s
library/node:latest	1425MiB	33385	1.18s	52.86s
library/ubuntu:22.04	83.4MiB	3517	0.15s	5.32s

现在有了 ID-mapped mount 的功能后，原本只有 UID=0/GID=0 用户可以访问的目录，只需几次系统调用就可以让 UID=1001/GID=1001 的用户访问。 ID-mapped mount 在内核层面实现 ID 映射，比传统的 chown -R 方法在性能和效率上都有显著提升。

NOTE: 具体细节可以查看之前的文章 - containerd 1.7: UserNamespace Stateless Pod

不过，ID-mapped mount 需要提供 user_namespace(7) 的句柄信息，而这种信息只能通过创建新进程（使用 CLONE_USER）来获取（/proc/$PID/ns/user 句柄）。由于 GO 对多进程编程的支持有限，标准库中只有 os.StartProcess 接口，而它采用了 fork 和 execve 组合的方式。换句话说，多进程的官方方法只能通过调用命令行来实现，这要求开发者为每个进程逻辑准备一个独立的二进制文件。为了简化运维，常见的做法是将每个独立逻辑封装成子命令，并通过调用自身的 /proc/self/exe 来完成，这种方法被称为 re-exec。

然而，这种方法的成本太高。相当于每个引用了 ID-mapped mount 功能的程序都需要一个专门的命令行来创建新的 user_namespace。因此，在 containerd 的 GetUsernsFD 中，模拟了 os.StartProcess 的 fork 流程，并将最后的 execve 替换为 syscall.RawSyscall(syscall.SYS_PPOLL, 0, 0, 0)，使子进程进入无限期的睡眠状态。这样，父进程 containerd 在 fork 返回时，子进程已经运行在新的 user_namespace 中，父进程可以安全地获取子进程的 user_namespace 句柄，而无需担心进程间的保活问题。

在整个 fork 过程中，子进程处于单线程模式，不具有完整的 GO runtime 逻辑。因此，需要使用 GO runtime 中的三个隐藏功能来屏蔽信号处理，并防止父子进程间发生栈大小的变化。这些隐藏功能只能通过 //go:linkname 指令来激活。在我看来，这本属于灵活使用，本身 GO 标准库都是这么玩的 :)。

//go:linkname beforeFork syscall.runtime_BeforeFork
func beforeFork()

//go:linkname afterFork syscall.runtime_AfterFork
func afterFork()

//go:linkname afterForkInChild syscall.runtime_AfterForkInChild
func afterForkInChild()

当然，子进程也只能使用 RawSyscall 来完成初始化工作。这是为了避免进入不应该进入的流程，例如释放当前的执行线程。

替换方案 ptrace

我并不想为了 fork 而引入一个子命令，所以给的选择也就只有 ptrace，如下面的代码所示。

os.StartProcess("/proc/self/exe", []string{"containerd[getUsernsFD]"}, &os.ProcAttr{
	Sys: &syscall.SysProcAttr{
		Cloneflags:  unix.CLONE_NEWUSER,
		UidMappings: uidMaps,
		GidMappings: gidMaps,
		// NOTE: It's reexec but it's not heavy because subprocess
		// be in PTRACE_TRACEME mode before performing execve.
		Ptrace:    true,
		Pdeathsig: syscall.SIGKILL,
	},
})

根据 ptrace(2) 的文档说明，在替换完程序入口指令后，子进程在返回用户态前会进入停止状态，即 tracing stop。以下是命令 retsnoop -e '*_send_signal_locked*' --comm exe -S 的输出示例。在执行 exec_binrpm 时，会触发 PTRACE_EVENT_EXEC 事件，然后在 exit_to_user_mode_loop 中处理掉该信号，使得进程主动进入 ptrace_stop 状态。

07:42:51.340953 -> 07:42:51.340956 TID/PID 2854060/2854060 (exe/exe):

              entry_SYSCALL_64_after_hwframe+0x73
              do_syscall_64+0x56
              x64_sys_call+0x680
              __x64_sys_execve+0x37
              do_execveat_common.isra.0+0x198
              bprm_execve+0x5e
              bprm_execve.part.0+0x17b
              exec_binprm+0x15a
              send_sig+0x29
              do_send_sig_info+0x63
              send_signal_locked+0xdd
!    2us [0]  __send_signal_locked


07:42:51.341038 -> 07:42:51.341043 TID/PID 2854060/2854060 (exe/exe):

              entry_SYSCALL_64_after_hwframe+0x73
              do_syscall_64+0x63
              syscall_exit_to_user_mode+0x17
              exit_to_user_mode_prepare+0xf4
              exit_to_user_mode_loop+0xaa
              arch_do_signal_or_restart+0x2a
              get_signal+0x5c1
              ptrace_signal+0x4e
              ptrace_stop.part.0+0x246
              do_notify_parent_cldstop+0x17d
              send_signal_locked+0xdd
!    4us [0]  __send_signal_locked

这与之前使用 poll 进入睡眠状态的本质是一样的，因为子进程并不需要执行具体的任务。有了这种能力后，可以直接使用 re-exec，利用现成的二进制文件。所以在 os.StartProcess 中，第一个参数直接指定为 /proc/self/exe。

os.StartProcess 通过配置一个带有 CLOEXEC 标志的匿名管道的写端来与子进程通信，该函数会在子进程进入 execve 系统调用的 do_close_on_exec 阶段后才返回。也就是说，当 os.StartProcess 返回时，子进程已经运行在了新的 user_namespace 中。

相比之前的方法，os.StartProcess 需要执行 execve 系统调用，这意味着它会读取程序的内容并解析入口指令的位置。虽然这种方法在成本上略高，但依然在可以接受的范围内。

goos: linux
goarch: amd64
pkg: github.com/containerd/containerd/v2/core/mount
cpu: AMD Ryzen 7 5800H with Radeon Graphics
                                    │ go122-golinkname │             go122-ptrace              │             go123-ptrace              │
                                    │      sec/op      │    sec/op     vs base                 │    sec/op     vs base                 │
BatchRunGetUsernsFD_Concurrent1-16        533.3µ ± ∞ ¹   739.6µ ± ∞ ¹        ~ (p=1.000 n=1) ²   723.3µ ± ∞ ¹        ~ (p=1.000 n=1) ²
BatchRunGetUsernsFD_Concurrent10-16       3.662m ± ∞ ¹   4.024m ± ∞ ¹        ~ (p=1.000 n=1) ²   3.957m ± ∞ ¹        ~ (p=1.000 n=1) ²
geomean                                   1.397m         1.725m        +23.45%                   1.692m        +21.06%
¹ need >= 6 samples for confidence interval at level 0.95
² need >= 4 samples to detect a difference at alpha level 0.05

                                    │ go122-golinkname │              go122-ptrace               │              go123-ptrace               │
                                    │       B/op       │     B/op       vs base                  │     B/op       vs base                  │
BatchRunGetUsernsFD_Concurrent1-16       1.118Ki ± ∞ ¹   3.855Ki ± ∞ ¹         ~ (p=1.000 n=1) ²   4.121Ki ± ∞ ¹         ~ (p=1.000 n=1) ²
BatchRunGetUsernsFD_Concurrent10-16      11.29Ki ± ∞ ¹   38.67Ki ± ∞ ¹         ~ (p=1.000 n=1) ²   41.36Ki ± ∞ ¹         ~ (p=1.000 n=1) ²
geomean                                  3.553Ki         12.21Ki        +243.65%                   13.06Ki        +267.43%
¹ need >= 6 samples for confidence interval at level 0.95
² need >= 4 samples to detect a difference at alpha level 0.05

                                    │ go122-golinkname │             go122-ptrace             │             go123-ptrace             │
                                    │    allocs/op     │  allocs/op   vs base                 │  allocs/op   vs base                 │
BatchRunGetUsernsFD_Concurrent1-16         43.00 ± ∞ ¹   68.00 ± ∞ ¹        ~ (p=1.000 n=1) ²   69.00 ± ∞ ¹        ~ (p=1.000 n=1) ²
BatchRunGetUsernsFD_Concurrent10-16        421.0 ± ∞ ¹   671.0 ± ∞ ¹        ~ (p=1.000 n=1) ²   682.0 ± ∞ ¹        ~ (p=1.000 n=1) ²
geomean                                    134.5         213.6        +58.76%                   216.9        +61.23%
¹ need >= 6 samples for confidence interval at level 0.95
² need >= 4 samples to detect a difference at alpha level 0.05

最后

在 core/mount: use ptrace instead of go:linkname 合并后，我第一时间给 GO 社区发起了退群请求 - 609996: runtime: update comment for golinkname.

[CONT] Non-Preemptible RCU soft lockup: zap_pid_ns_processes

Mon, 10 Jun 2024 14:00:45 +0800

接着上一篇 Non-Preemptible RCU soft lockup: zap_pid_ns_processes。根据内核维护者的回复和修复补丁，已经确定是和 io_uring(7) worker 唤醒机制有关。

io_uring io-wq worker pool

根据 Redesigned workqueues for io_uring 文章的描述，io_uring 使用 workqueue 处理异步 IO 请求有局限性，因此在 io-wq: small threadpool implementation for io_uring 补丁里开始用线程池来替代 workqueue。

当用户态进程通过 io_uring_enter(2) 系统调用提交 io 请求，io_uring 模块会将 io 请求放入到队列里，并按需创建内核线程 io_wqe_worker 来处理请求，如下图的上半部分。

NOTE: 该图来源于 https://blog.cloudflare.com/missing-manuals-io_uring-worker-pool

以该 package.json 为例，nodejs-20.11.0 默认开启 io_uring，在 npm run done 前，nodejs 会利用 uv__iou_fs_statx 函数来获取当前文件系统的信息。这个 io_uring statx io 请求会触发内核创建 io_wqe_worker 线程。那么我们看下 npm run zombie 长时间运行的程序都有哪些线程。如下图的下半部分为例，1147997 进程有两个 iou-wrk-1148006 的线程。 io_wqe_worker 线程会以调用 io_uring_enter 的线程 ID 来命名 iou-wrk-%d，因此 iou-wrk-1148006 内核线程是由 1148006 线程创建的。

当创建 io_wqe_worker 的用户线程退出时，那么内核会在 do_exit.io_uring_files_cancel 函数里唤醒 worker 并告知它应该结束工作。

TIF_NOTIFY_SIGNAL

就目前了解到细节来看，线程的信号处理更像是调度处理（以打标记为主）。负责发送信号的线程除了添加信号信息外，它还需要把目标线程标记上 TIF_SIGPENDING；当目标线程准备从系统调用返回用户态时，目标线程会在 exit_to_user_mode_loop 检查 TIF_SIGPENDING 是否存在；如有信号到来，那么线程将调用 handle_signal_work 处理信号，它有可能会回到用户态，比如用户自定义的 SIGUSR1 信号处理。同样，io_uring 也是通过添加 TIF_SIGPENDING 标记的方式来唤醒 io_wqe_worker。

但根据 task_work: use TIF_NOTIFY_SIGNAL if available 补丁来看，早期 io_uring 通过 jobctl 来进行信号标记，但这个方式需要对线程的 task->sighand 属性进行加锁；当进程是多线程程序时，锁对性能的影响比较大。因此 io_uring 引入了新的标记 TIF_NOTIFY_SIGNAL 避免锁的影响。

当创建 io_wqe_worker 的线程退出后，那么该线程会把 IO_WQ_BIT_EXIT 标记成 1, 并将所有相关的 io_wqe_worker 线程都标记上 TIF_NOTIFY_SIGNAL 并唤醒让其退出。

但我们看看 io_wqe_worker 关键代码，整个过程里，该线程只有在 io_flush_signals 里有机会消除这个 TIF_NOTIFY_SIGNAL 标记，那么 io_wqe_worker 线程是有可能带着这个标记进入到 zap_pid_ns_processes 阶段，从而导致 CPU 无法运行其他线程。

// v5.15.160
static int io_wqe_worker(void *data)
{
	// ...
	// IO_WQ_BIT_EXIT=1 表示 worker 应该结束工作
	while (!test_bit(IO_WQ_BIT_EXIT, &wq->state)) {
		// ...

		// 清除 TIF_NOTIFY_SIGNAL
		if (io_flush_signals())
			continue;

		// 没任务时，将进入睡眠态
		ret = schedule_timeout(WORKER_IDLE_TIMEOUT);

		// 检查当前线程是否有以下两个标记
		//   TIF_SIGPENDING
		//   TIF_NOTIFY_SIGNAL
		if (signal_pending(current)) {
			struct ksignal ksig;

			// 取出信号
			if (!get_signal(&ksig))
				continue;
			break;
		}
		// ...
	}
	// ...
	// 调用 do_exit(0);
	io_worker_exit(worker); 
}

io_wqe_worker thread is last one in init

现在有一个进程 X，它运行在新的 pid_namespace(7) 以及 mount_namespace(7) 里。它只有两个线程，它们分别是 X-1 以及 X-iou-wrk-1。除此之外，X 还有一个孩子进程 Y。进程 Y 和 X 运行在相同的 namespace 下。

进程 X 作为它所在 pid_namespace 里是 一号进程。当进程 X 主线程 X-1 退出时，它会给 X-iou-wrk-1 线程发送 SIGKILL 信号并唤醒它。如果 X-iou-wrk-1 线程还没完全从 io_wqe_worker 上下文里结束，线程 X-1 有机会给 X-iou-wrk-1 标记上 TIF_NOTIFY_SIGNAL。

如果 X-1 提前结束, X-iou-wrk-1 将会是一号进程里唯一非 zombie 线程，它将负责清理在这个 pid_namespace 下的所有进程，比如这里的进程 Y。线程 X-iou-wrk-1 将进入 zap_pid_ns_processes 来清理进程 Y。

// v5.15.160
void zap_pid_ns_processes(struct pid_namespace *pid_ns)
{
	// ...

	// 给当前 pid_namespace 下的所有线程发送 SIGKILL
	// 根据前面的假设，这里只有进程 Y。
	rcu_read_lock();
	read_lock(&tasklist_lock);
	nr = 2;
	idr_for_each_entry_continue(&pid_ns->idr, pid, nr) {
		task = pid_task(pid, PIDTYPE_PID);
		if (task && !__fatal_signal_pending(task))
			group_send_sig_info(SIGKILL, SEND_SIG_PRIV, task, PIDTYPE_MAX);
	}
	read_unlock(&tasklist_lock);
	rcu_read_unlock();

	// 给进程 Y 发送 SIGKILL 后，还需要回收 Y
	do {
		// 清理掉 TIF_SIGPENDING
		// 如果有新来的 TIF_SIGPENDING 信号
		// 那么 kernel_wait4 就有机会释放 CPU
		clear_thread_flag(TIF_SIGPENDING);
		rc = kernel_wait4(-1, NULL, __WALL, NULL);
	} while (rc != -ECHILD);

	// ...
}

kernel_wait4.do_wait 遇到没有可以回收的线程时，它会判断是否需要处理信号。如果没有信号需要处理，那么它将调用 schedule 来释放当前 CPU。在没有开启抢占模式的内核下，进入内核态的线程只能主动释放 CPU，比如结束系统调用或者主动调用 schedule。不然它将长期霸占所在的 CPU。

// v5.15.160
static long do_wait(struct wait_opts *wo)
{
	
	// ...

notask:
	retval = wo->notask_error;
	if (!retval && !(wo->wo_flags & WNOHANG)) {
		retval = -ERESTARTSYS;
		// 没有可以回收线程，比如 D 状态的线程
		// 假设没有信号需要处理，那么线程主动释放 CPU
		if (!signal_pending(current)) {
			schedule();
			goto repeat;
		}
	}
 
	// ...
}

然而线程 X-iou-wrk-1 身上一直有 TIF_NOTIFY_SIGNAL 标记，导致 signal_pending 一直返回 True, 它永远都走不到 schedule 这个函数。而进程 Y 收到信号后退出，它是最后一个引用 mount_namespace 的进程，它将负责回收 mount_namespace 相关的资源，并进入到 synchronize_rcu_expedited 函数。而 synchronize_rcu_expedited 要求所有 CPU 都要上报静止态，也就是至少发生过一次上下文切换。但线程 X-iou-wrk-1 并不会释放 CPU，所以进程 Y 无法从 synchronize_rcu_expedited 中离开从而长期处于 D 状态，形成了一个死锁。

# 进程 Y
$ sudo cat /proc/2522605/task/2522645/stack
[<0>] synchronize_rcu_expedited+0x177/0x1f0
[<0>] namespace_unlock+0xd6/0x1b0
[<0>] put_mnt_ns+0x73/0xa0
[<0>] free_nsproxy+0x1c/0x1b0
[<0>] switch_task_namespaces+0x5d/0x70
[<0>] exit_task_namespaces+0x10/0x20
[<0>] do_exit+0x2ce/0x500
[<0>] io_sq_thread+0x48e/0x5a0
[<0>] ret_from_fork+0x3c/0x60
[<0>] ret_from_fork_asm+0x1b/0x30

$ sudo cat /proc/2522605/task/2522645/status
Name: iou-sqp-2522605
State: D (disk sleep)
# ...

后续任何回收 mount_namespace 的操作都将卡死，只有重启系统才可以缓解。这个问题的修复也比较简单，就是在进入 kernel_wait4 之前清理掉 TIF_NOTIFY_SIGNAL 标记即可。

diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index dc48fecfa1dc..25f3cf679b35 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -218,6 +218,7 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns)
 	 */
 	do {
 		clear_thread_flag(TIF_SIGPENDING);
+		clear_thread_flag(TIF_NOTIFY_SIGNAL);
 		rc = kernel_wait4(-1, NULL, __WALL, NULL);
 	} while (rc != -ECHILD);

Summary

如果你是从事容器开发的朋友，应该对函数 zap_pid_ns_processes 不陌生，遇到就只能献上重启大法 QQ。本次分享的问题只有使用 io_uring 的容器应用才会遇到。对于 nodejs 而言，如果 io_uring 不是刚需，可以考虑用 UV_USE_IO_URING=0 关闭掉。

最后，根据内核大佬的说法，zap_pid_ns_processes 这个函数已经遇到过很多问题，不排除还有其他坑 T.T。

Non-Preemptible RCU soft lockup: zap_pid_ns_processes

Thu, 06 Jun 2024 07:47:45 +0800

分享一个最近遇到的容器问题吧，虽然还不知道该怎么解决，但已经发信给内核社区寻求帮助了。

[RCU] zombie task hung in synchronize_rcu_expedited

这是一个关于 zap_pid_ns_processes.kernel_wait4 死循环的问题，因为没有开启内核的 抢占模式，似乎处于 zap_pid_ns_processes.kernel_wait4 调用栈的线程没法进行上下文切换，导致 synchronize_rcu_expedited 卡死，容器无法正常释放 mount_namespace。目前我可以在 v5.15/v6.1/v6.5/v6.9/v6.10-rc2 内核版本上复现该问题，而且在 v5.15 内核上尤其容易复现。

注: 编译条件可以查看文章的最后。

Non-Preemptible RCU synchronize_rcu_expedited

RCU 是一个极其复杂的话题，本节关于 RCU 的描述会存在不准确或者不正确的可能性。本人仅在复现 soft lockup 问题上表达自己对不可抢占 RCU 的一些理解，对于更官方或者更准确的表达，应该查阅 RCU 的官方文档。

Read-Copy-Update 是内核里对并发读比较友好的同步机制。与传统的互斥锁不同，RCU 利用 CPU 上下文切换来反馈进程是否离开了临界区。

rcu_read_lock()
// RCU read-side critical section
rcu_read_unlock()

RCU 临界区内不可自行调用 schedule 来进行 CPU 线程的上下文切换。因此非抢占模式下的 CPU 线程发生上下文切换时，比如内核态返回用户态或者执行其他进程时，那么当前 CPU 一定离开了 RCU 临界区。内核没有内存垃圾回收机制，因此当受 RCU 临界区保护的数据需要更新时，更新者要负责回收正在被 RCU 临界区访问的老数据。因此 RCU 的更新操作分两个阶段：删除和回收。

// https://lwn.net/Articles/262464/#Publish-Subscribe%20Mechanism

q = kmalloc(sizeof(*p), GFP_KERNEL);
*q = *p;
q->b = 2;
q->c = 3;
// Removal
list_replace_rcu(&p->list, &q->list);
synchronize_rcu();
// Reclamation
kfree(p);

删除操作本质上是赋值，表示当前的数据已指向新的内存地址。但更新前的数据内存可能正在被其他 CPU 线程访问，更新者无法直接释放这块内存，它需要等待所有 CPU 线程都离开了临界区。

在具体实现细节里，每一个 CPU 线程都有 Quiescent State 标志。当 CPU 线程正在访问 RCU 临界区时，我们称之为 活跃态；当 CPU 离开临界区后并发生上下文切换时，那么我们称之为 静止态。 RCU 数据更新者 在更新完数据后，它需要调用 synchronize_rcu 函数等待所有 CPU 线程上报静止态，这段等待时长称之为 Grace Period 宽限期。如下图所示，CPU 1 和 CPU 2 分别离开 Reader 1-1 和 Reader 2-1 临界区后上报静止态；而 CPU 3 启发宽限期时，CPU 0 已经属于空闲状态，因此后续 Reader 0-2 临界区访问的是新的数据内存，不存在释放内存的风险。因此宽限期在 CPU 2 上报静止态后结束。宽限期后并没有代码会继续访问老的数据内存，CPU 3 可以放心释放这段内存空间。

synchronize_rcu 主动等待其他 CPU 线程上报静止态，可能存在长延迟的情况。内核提供了 synchronize_rcu_expedited 函数来加速其他 CPU 线程上报静止态的效率。 synchronize_rcu_expedited 会主动给 non-idle no-hz CPU 线程发送 IPI 中断。以 v5.15 内核代码为例，synchronize_rcu_expedited 会启动 kernel worker 去运行 wait_rcu_exp_gp, 然后等待所有的 CPU 线程上报静止态。 wait_rcu_exp_gp 会调用 smp_call_function_single 给 CPU 线程发送 IPI 中断，随后对应的 CPU 线程会进入到 rcu_exp_handler。在 rcu_exp_handler 的逻辑里，如果发现 CPU 线程原本属于空闲状态，那么它将立刻上报静止态。如果不是，那么它将当前进程标记成可抢占，一旦该进程满足被抢占条件后，该 CPU 线程就会出现上下文切换并上报静止态。

// v5.15.160

/* Request an expedited quiescent state. */
static void rcu_exp_need_qs(void)
{
	__this_cpu_write(rcu_data.cpu_no_qs.b.exp, true);
	/* Store .exp before .rcu_urgent_qs. */
	smp_store_release(this_cpu_ptr(&rcu_data.rcu_urgent_qs), true);
	set_tsk_need_resched(current);
	set_preempt_need_resched();
}

/* Invoked on each online non-idle CPU for expedited quiescent state. */
static void rcu_exp_handler(void *unused)
{
	struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
	struct rcu_node *rnp = rdp->mynode;

	if (!(READ_ONCE(rnp->expmask) & rdp->grpmask) ||
	    __this_cpu_read(rcu_data.cpu_no_qs.b.exp))
		return;
	if (rcu_is_cpu_rrupt_from_idle()) {
		rcu_report_exp_rdp(this_cpu_ptr(&rcu_data));
		return;
	}
	rcu_exp_need_qs();
}

但如果目标 CPU 线程进入了内核态，而且内核关闭了可抢占的功能，那么 synchronize_rcu_expedited 函数只能等待目标 CPU 线程自己切换上下文了。

put_mnt_ns.synchronize_rcu_expedited stuck

现在我们使用的容器一般都会配置 pid_namespace(7) 和 mount_namespace(7) 分别做进程视图隔离以及挂载点隔离。在新的 pid_namespace PA 里，一旦一号进程退出，一号进程会在 do_exit.exit_notify 里调用 zap_pid_ns_processes 给 PA 下的所有进程发送 SIGKILL 信号，并主动回收僵尸进程。假设只有这个 PA 下的进程使用了 mount_namespace MA，那么当最后一个线程进入到 do_exit.exit_task_namespaces 阶段时，它回收 mount_namespace MA 资源。put_mnt_ns.drop_collected_mounts 释放完资源后，它会调用 synchronize_rcu_expedited。

现在遇到的问题是，没有开启抢占模式的情况下，因为某种原因导致某个 CPU 线程卡在 zap_pid_ns_processes.kernel_wait4 阶段。那么这将导致调用 synchronize_rcu_expedited 的线程也将进入 Disk Sleep 状态。因为内核并不允许并发调用 synchronize_rcu_expedited，其他容器在退出时，那么必定会有线程进入到 exp_funnel_lock 等锁状态。

为了方便复现这个卡顿问题，我们使用 GO 程序来 re-exec 自身来构造出以下进程树。

unshare(CLONE_NEWPID|CLONE_NEWNS)     [Start]
		 |
		 |
		 v
rcudeadlock task && rcudeadlock start [Entrypoint]
		 |
		 |
		 v
rcudeadlock start                     [PID 1 and exit]
   |___ rcudeadlock zombie
         |__ bash -c "while true; echo zombie; sleep 1; done"

以下使用 Ubuntu v5.15.0-1064-azure 内核复现的日志，可以看到 rcudeadlock start (pid 2928) 进入 kernel_wait4 状态，并长时间霸占 CPU #2 线程上；而它的孩子进程 sleep (pid 3141) 等待在了 synchronize_rcu_expedited。如果后续还有新的进程需要回收 mount_namespace，那么这些进程都将卡在 synchronize_rcu_expedited。

目前还不知道具体原因，但比较有意思的是，一旦在 rcudeadlock 进程中引入 io_uring(7) 空闲线程后，这个问题就特别容易复现。

How to build kernel to reproduce this issue?

编译内核需要关闭 CONFIG_PREEMPT 以及 CONFIG_PREEMPT_RCU，大致如下图所示。

$ cat /boot/config-5.15.0-1064-azure | grep _RCU
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_TASKS_RCU_GENERIC=y
CONFIG_TASKS_RUDE_RCU=y
CONFIG_TASKS_TRACE_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_RCU_NOCB_CPU=y
CONFIG_MMU_GATHER_RCU_TABLE_FREE=y
# CONFIG_RCU_SCALE_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_REF_SCALE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=60
# CONFIG_RCU_TRACE is not set
# CONFIG_RCU_EQS_DEBUG is not set

$ cat /boot/config-5.15.0-1064-azure | grep _PREEMPT
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_DRM_I915_PREEMPT_TIMEOUT=640
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set

目前在 8 vcores 环境下，运行 rcudeadlock 容易复现。在 v5.15 内核环境下，大概就几分钟的时间就可以复现。而在 >= v6.5 环境下复现时间不固定，有时候需要花几个小时, v6.10-rc2 内核依旧可以复现。

脏页大小 - 18446744073709551614 ?!

Thu, 11 Apr 2024 20:48:45 +0800

分享一个 etcd-io/etcd@17615 问题：用户发现 etcd 进程写入 WAL 日志有抖动，但是磁盘压力并不大，而且 fsync 系统调用都很正常；后来通过 Tracing 工具定位到了内核 memory-cgroup 脏页数据统计有问题，不过该问题仅会出现在 v5.15.0-63 小版本。 17615 问题单里有详尽的定位过程，推荐看看。因为这个问题，我翻阅了相关的内核 PATCH 邮件，做了以下的脏页分配限流 (简单) 总结。

脏页分配限流 - balance_dirty_pages

回写 (Writeback) 是指内核负责将脏页 (DirtyPage) 刷入存储设备上，它涉及到脏页分配控制。

在 v4.2 版本之前，脏页分配更多是由 memory-cgroup 来控制；而脏页流控核心 - balance_dirty_pages - 根据全局的脏页水位情况来决定是否需要控速。在 LinuxCon Japan 2015 会议上，内核开发者 Tejun Heo 认为，在没有感知到全局脏页水位的情况，memory-cgroup 无法对脏页进行有效的控制。核心 balance_dirty_pages 函数通过 vm.dirty[_background]_{ratio, bytes} 参数来计算全局脏页的水位上限。 Tejun Heo 认为普通的 memory-cgroup 也应采用同样的方式来计算组内的脏页水位上限，而根组 memory-cgroup 只不过是退化到全局模式，当然全局脏页的水位优先级更高。

NOTE: balance_dirty_pages_ratelimited 会调用 balance_dirty_pages。

在 writeback: cgroup writeback support PATCH 合并到 v4.2 之后，每个 memory-cgroup 都有独立的设备回写控制器 (bdi_writeback)，它用于执行回写操作。回写控制器维护写入带宽 - dirty_ratelimit - ，初始状态下为 100 MiB/s。假设当前脏页大小为 dirty 和同时有 N 个线程在写入，该线程需要等待的时长大约为

pause = dirty / (dirty_ratelimit / N)

在 writeback: dirty rate control PATCH 里，内核开发者 Wu Fengguang 给出了 N = roundup_pow_of_two(1 + HZ / 8) 的计算方法；自 2011 年以来，内核一直在使用该方法计算 N。让线程停顿是为了防止脏页增长过快。但如果整体可用内存水位状态良好，内核应该尽量避免不必要的停顿，因此脏页水位有三个状态 freerun, setpoint 和 limit。

threshold = vm.dirty_ratio * total_available_memory 
background_threshold = vm.dirty_background_ratio * total_available_memory

* freerun = (threshold + background_threshold) / 2
* limit = threshold
* setpoint = (freerun + limit) / 2

当脏页水位线低于 freerun 时，那么线程并不需要停顿，内存允许脏页快速增长；当脏页水位高于 limit 时，内核将通过 sleep(pause) 来禁止线程写入新的脏页，内核需要通过回写来降低水位线到安全的位置。为了更好地计算停顿时长，内核引入了线程级别的带宽概念 task_ratelimit: 利用水位状态 pos_ratio 来调节写入带宽。

* pos_ratio(dirty) = 1.0 + ((setpoint - dirty) / (limit - setpoint) ) ^3 
* task_ratelimit(dirty) = dirty_ratelimit * pos_ratio(dirty)

* pause = dirty / (task_ratelimit / N)

内核还会根据 IO 回写控制器的情况来微调 pos_ratio，尤其是在内存较大的机器上能充分利用内存优势，通过维持较高的写入带宽来迅速降低脏页水位线，细节可以查询 writeback: dirty position control PATCH。

memory-cgroup 脏页状态更新 - rstat

当进程跑在非根组的 memory-cgroup 时，balance_dirty_pages 需要从对应 memory-cgroup 获取当前的脏页大小。

2019 年 mm: memcontrol: make cgroup stats and events query API explicitly local PATCH 让内核在更新侧 (内存的分配和释放) 做 per-cpu 的批量数据聚合，减少读取侧因遍历 memory-cgroup 树形结构测带来的 CPU 消耗。假设每次更新 32 个页的数据，在 32 CPU 下运行着 32 个 memory-cgroup，那么最大误差会在 128 MiB 左右。为了解决误差和读取效率问题，内核开发者 Johannes Weiner 在 mm: memcontrol: switch to rstat PATCH 里引入了 rstat 框架: 更新侧仅需为祖辈们维护 pending-update cgroup 队列，而读取侧仅选择性地做数据聚合，减少了不必要的遍历。

假设当前 memory-cgroup 结构为 root -> A -> B -> C，当线程在 C 内分配了内存，那么内核在更新 C 的同时，它也会标记 B, A, root 为待更新状态；当有线程需要读取 C 状态时，那么读取侧需要将 B, A, root 也更新了，才能保证 root -> A -> B -> C 链路上的数据是一致的。如果新增了 root -> A -> D -> E memory cgroup, 但 D, E 没有数据的变化，那么在读取 C 的数据时，内核并不会遍历 D, E。 rstat 架构的选择性聚合优化了读取效率和准确性。关于 rstat 的更多细节可以查看 Linux Plumbers Conferences 2022 - cgroup rstat’s advanced adoption。

脏页大小 - 18446744073709551614 ？

回到 ETCD 遇到的这个问题上。在更新 memory-cgroup 字段时，线程仅更新当前 CPU 的 memcg->vm_stats_percpu->state 上，由读取侧调用 cgroup_rstat_flush_locked 函数来做 CPU 级别的数据聚合。

那么问题来了，假设有 32 个 CPU，当 cgroup_rstat_flush_locked 读取第三个 CPU 上的数据时，第一个 CPU 产生了新的脏页，然后被第 30 个 CPU 刷盘了。错过了第一个 CPU 产生的增量，导致在那个时刻的统计结果里脏页是负数。虽然状态最终是正确的，但负数被转化成 unsigned long 将变成非常大。

static inline unsigned long memcg_page_state(struct mem_cgroup *memcg, int idx)
{
        return READ_ONCE(memcg->vmstats.state[idx]);
}

根据前面提到的停顿时长计算公式，线程相当于无限期停服了。好在内核允许的最大停顿时间为 200 ms，下一轮检查大概率就恢复正常了。 Revert “memcg: cleanup racy sum avoidance code PATCH 修复也非常简单，就是回滚之前的一个 PATCH。

我在一个 CPU 32 vcores - Memory 64 GiB 虚拟机上复现了这个问题：

* 单实例 ETCD 运行在 /sys/fs/cgroup/testing1 里，并使用 ETCD benchmark 疯狂发写请求
* 反复在 /sys/fs/cgroup/testing2 里运行 dd 来产生大量的脏页，迫使 ETCD 进程进入 balance_dirty_pages

通过 Tracing Event 日志发现，脏页大小为 18446744073709551614 (-2)。

核数越多，越容易遇到这个问题。

最后

博客停更好久了，有时间就多写写吧。

同步近期 containerd 的高频问题

Sun, 13 Aug 2023 23:48:45 +0800

最近 Issue 8698 有用户说容器启动和清理都偏慢，尤其多个 Pod 同时启动时现象特别明显。之前有过类似的问题: containerd 启动容器前，它需要临时挂载 rootfs 来读取 uid/gid 信息。因为挂载的是可写属性的 overlayfs，卸载时内核会强制刷盘。当系统大量的脏页数据需要回写时，这个刷盘动作容易造成系统卡顿。 oci: use readonly mount to read user/group info 已经解决读取 uid/gid 的性能问题了，但这一次是 Pod Init-container 带来的。

Init-container rootfs 大部分都是可写模式的 overlayfs，如果 Init-container 是做数据预下载的话，那么 containerd 在删除 Init-container 时，内核一定会刷盘。在大部分场景下，同一个节点上的 Pod 共享同一块数据盘，这种不预期的刷盘很容易把系统打崩。还有 Issue 8647 用户说，他的系统一开始还好好的，跑几天就不稳定了。后来查看他提供的日志，发现有几个 Pod 一直启动失败，相当于每隔几秒都要去刷盘，导致整个系统不稳定。

这个问题的最佳解决方案应该是做好 Pod 的存储隔离，但显然这成本确要高不少。然而 Kubernetes 场景下的容器并不会重启，即使在「失败后无限重启」的策略下，kubelet 依然是删除重建，这也意味着容器 rootfs 并不需要持久化。个人觉得，成本最低的解决方案应该是使用 overlayfs-volatile-mount，它需要 Linux Kernel ≥ 5.10。以下是个人目前了解到的情况，大部分云厂家都支持了 overlayfs-volatile。

Azure Ubuntu 22.04 LTS - Kernel 5.15 (GA)
AWS Kubernetes ≥ 1.24 使用 Kernel 5.10
阿里云 Alibaba Cloud Linux 2 使用 Kernel 4.19，但它支持 volatile
Google 支持的发行版比较多，包含了 Ubuntu 22.04 TLS - Kernel 5.15
华为云 Huawei Cloud EulerOS 2.0 使用 Kernel 5.10

除此之外，还有 Issue 7496 Issue 8931 用户报告说 umount 刷盘耗时太长导致 containerd-shim 泄露。其实这个问题的根因并不在于 umount，而是 containerd 清理 shim 的流程忽略了一些关键错误，导致上层调用者 (比如 CRI 插件) 没有重试机会，进而出现了 shim 泄露问题。PR 8954 仅修复 umount 超时带来的泄露，但可能会出现因 shim.Shutdown 超时带来的泄露。要完全修复 shim 泄露问题，containerd 应该让上层调用者发起删除，而不是通过异步来做清理。这里涉及到 containerd event 的可靠性以及上游 moby/moby 使用的调整，估计要讨论上一段时间，所以 PR 8954 也仅是降低泄露风险。

如果有遇到该问题的朋友，可以关注下 Cherry-pick: [overlay] add configurable mount options to overlay snapshotter ，尽量使用 volatile 来避免刷盘带来的影响。

containerd v1.7 系列文章的最后一篇被我鸽了，考虑到最近华为云提议的 Sandbox: make sandbox controller plugin 特性还在讨论阶段，等到 v2.0 在补一篇好了。下次一定！

containerd 1.7: 垃圾回收的拓展

Sun, 19 Mar 2023 19:48:45 +0800

之前和苦总/Ace 维护 pouch-container/containerd 的时候，我们遇到比较多的问题是资源泄漏，比如节点负载太高以至于无法 umount 容器根目录(容器 bundle 目录残留），内核 pidns 死锁问题导致容器进程僵尸态( cgroup 残留)，还有进程重启导致 CNI 网络资源泄漏等等。对于内核死锁等问题，重启可能是唯一的解决方案；而那些因为短期高负载或者进程重启导致的资源泄漏，它们需要从系统层面解决，至少应该让资源的创建者有机会去清理。

containerd 它本身就具备垃圾回收能力，但它只关注内部资源的清理，比如镜像数据以及容器可写层。而 CNI 网络资源以及 containerd-shim 等外部资源并不在垃圾回收的管理范围内，这部分资源容易出现泄漏的情况，比如 GKE 平台的用户就多次遇到了 Containerd IP leakage : 直到 pause 容器创建之前，containerd 仅在内存里保持对网络资源的引用；在将网络资源绑定给 pod 以前，containerd 一旦被强制重启就会发生泄漏。当时 containerd 社区的处理方式是提前创建 pod 记录，以此来提前关联网络资源，并利用 kubelet 的垃圾回收机制来触发资源清理。问题倒是解决了，但该方案仅适用于 kubernetes 场景，最合理的方案应该是创建者应具备周期性的清理流程。

考虑我们还有 shim 资源泄漏的问题，containerd 社区提了 Add collectible resources to metadata gc 方案来管理外部资源清理。在介绍这个方案之前，我想先介绍下 containerd 的垃圾清理机制。

基于标签系统和 lease 构建的垃圾回收

containerd 核心插件 metadata 管理着容器和镜像数据，如下图所示，其中虚线方块代表着子模块，比如 Images 代表着 image service，它仅用来管理镜像名字和镜像 manifest 的映射关系，而镜像的 blob 数据和解压后的文件内容分别由 content service 和 snapshot service 管理；需要说明的是，container service 仅用来保存用于启动容器的配置信息，它并不负责管理容器进程的生命周期。

上图的方向键代表着数据之间的关联性，但除了 image/container 可以直接指向其相关联的数据外，content 数据间的关系以及 content 和 snapshot 数据间的关系都将通过标签系统来维系。

根据 OCI 镜像标准的定义，镜像 manifest 的数据内容会关联其配置信息 config 以及 layer 的数据。在 containerd content service 里，这些数据的关系将由标签 containerd.io/gc.ref.content. 来呈现，如下图的所示。

busybox:1.25 镜像名字关联着一个哈希值为 sha256:29f5d56d1… 的 manifest，而这个 manifest 身上有两个重要的标签，如下表所示，它们分别指向了 config 和 layer 哈希值。由于每一层 layer 数据都对应着一个 snapshot，而这些 snapshot ID 是来自 config 里的 diffID 所生成的 chainID。为了管理方便，containerd 在 config 上添加标签 containerd.io/gc.ref.snapshot.X 来关联最后一层 snapshot，其中 X 表示具体的 snapshotter 插件，比如 linux 平台常用的 overlayfs。

Key	Value	Ref
containerd.io/gc.ref.content.config	sha256:e02e811dd…	config
containerd.io/gc.ref.content.l.0	sha256:56bec22e3…	layer

containerd.io/gc.ref.content.l.N 用来指向具体的镜像层，N 代表的是第几层。

现在我们回头看第一张图，container/image 的元数据就可以作为垃圾回收的 GC-Root，containerd 配合标签系统进行全局扫描，并通过 Tricolor 来获得正在使用的数据，那些没有被关联到的数据就可以被删除。

比如我们将 redis:latest 镜像删除之后，redis:latest 镜像关联的 manifest sha256:78CF547… 没有可达的路径；同样地，redis:latest 镜像的 config sha256:B5CC793… 也没有可达路径。但图中的 redis:latest 镜像是基于 alpine:latest 构建，所以 redis:latest 镜像的第一层 sha256:3B87DCE… 将被保留；加上 Redis container 容器关联的可写层 Contaner Root 是基于 redis:latest 构建，因此垃圾回收仅会清理没有可达路径的 content 数据。

如果在此基础上删除 Redis container，那么 Redis + Alpine 和 Container Root snapshot 将没有可达路径，它们也将会被垃圾回收清理。在这里也侧面解释了 为什么 containerd 允许用户删除正在被容器使用的镜像: 垃圾回收并不会真正去清理容器根目录所依赖的 snapshot，只有等到没有容器或者镜像引用时，containerd 才会真正去删除镜像相关的数据。

前面提到了标签系统如何关联数据，那么你可能会问，containerd 垃圾回收流程会清理正在下载的镜像数据吗？毕竟调用 image service 关联 mainifest 是下载流程的最后步骤。如果没有 lease 关联，containerd 会清理正在下载的镜像数据。

下载镜像是一个不可控的事务，它的耗时由镜像大小、网络带宽以及磁盘读写能力来决定。为了避免未关联的临时数据被删除，containerd 引入了 lease 数据作为新的 GC-Root。它和 image/container 数据平级，它所关联的 content/snapshot 不会被垃圾回收清理。因此下镜像的第一步就是去申请 lease。

如上图所示，我中途取消了 golang:1.20.1 镜像的下载，其中一个 layer sha256:543368fb… 没有被清理掉，因为它已经被 lease 650284033-Pgbh 关联上了。一般情况下，lease 数据上都会有标签 containerd.io/gc.expire 来表明过期时间。过期之后，lease 和它关联的数据都会被 containerd 清理。如果我没有删除 lease，而是选择重新下载 golang:1.20.1 镜像，containerd 可以恢复取消前的状态，它具备 断点续传 的能力。

新版本的拓展能力

前面提到的垃圾回收仅针对容器和镜像数据，并没有涉及其他资源。但标签系统足以将 metadata 定义的 GC-Root 资源关联到外部组件定义的资源信息，现在仅需要 containerd 提供垃圾回收的标记机会即可。为此， containerd 社区为 metadata 插件引入了 GC Collector 插件接口，如下图所示。

在标记 GC-Root 阶段，containerd 给予 GC Collector 三种方式标记:

第一种是在扫描 lease 资源的阶段。在扫描某一个 namespace 下的 lease 时，containerd 将通过 CollectionContext.Leased() 方法来告知插件: 请把当前 namespace 下所有跟这个 lease 有关的数据都通过 fn 回传回来。目前 streaming service 主要采用这种方式标记。
第二种是扫描 container/image 数据标签的阶段。Collector.ReferenceLabel() 告知了 containerd 它感兴趣的标签，这个标签以 containerd.io/gc.ref. 开头。比如 CNICollector 插件用来管理容器的网络资源，它维护容器和 netns 路径间的关联关系。当 container 数据创建时，它的 netns 路径为 /run/netns/demo，那么开发者可以为 container 数据添加一条标签 containerd.io/gc.ref.cni=/run/netns/demo。当 containerd 在扫描 container 数据时，它会将 /run/netns/demo 作为可达对象。
第三种是扫描完某一个 namespace 的路径发起点之后，containerd 会调用 CollectionContext.Active() 来告知插件：请把当前 namespace 下所有正在使用的数据通过 fn 回传回来。

当 containerd 标记完所有 GC-Root 后，它会扫描所有数据，并删除没有被关联到的数据；之后它将调用 CollectionContext.All() 来遍历插件维护的所有数据，并调用 CollectionContext.Remove() 来清理没被关联上的数据；最后调用 CollectionContext.Finish() 来结束本次清理。

有了这个拓展包之后，理论上所有和容器相关的资源都可以被监控起来，比如开头提到的 CNI 网络资源、containerd-shim 进程，甚至是 containerd-shim 创建出来的 socket 文件。

但需要明确的是，这个拓展包针对的是 containerd 开发者，并不是终端用户。

containerd v2.0 计划

目前比较明确的是，由 AWS 开发者主导的 [Proposal] Add Networks Service Plugin 会重新改变现有 CRI 的网络管理方式。而像 shim process leaked when the host having high disk i/o usage 这些泄漏问题，可能会涉及到 Sandbox API 的改造，进展应该不会太快吧。

最后

这次没有展开解释 containerd 如何清理 snapshotter 数据，个人觉得这部分设计还是不错的，感兴趣的开发者可以去看看这部分实现。这次就到这吧，下一篇会是 containerd 1.7 特性系列介绍的最后一篇。

containerd 1.7: Image Transfer Service

Mon, 13 Mar 2023 01:20:45 +0800

从 HELM Chart 成功对接容器镜像仓库开始，到近两年 OCI 社区 artifacts 标准化的落地推广，现在 OCI Registry as Storage 已经是事实标准，不同业务场景的数据存储都可以对接 OCI registry 的分发协议。同时，这几年容器镜像的安全供应链需求徒增，以及各大云厂商对容器镜像 lazy-loading 探索力度在加大，OCI 社区在 artifacts 标准的基础上为容器镜像引入 referrers 定义：在保证前后兼容的情况下，每一个容器镜像都可以通过关联的 artifacts 来拓展自身的属性，如下图所示，用户可以通过 referrers 关联特性为 net-monitor:v1 镜像提供了镜像签名和 SBOM 信息。当然，容器镜像 lazy-loading 属性也可以与之相关联，比如阿里云的 overlaybd，蚂蚁金服的 nydus 以及亚马逊的 soci。

NOTE: 图片取自 Feynman Zhou 发表的 Azure Container Registry: the first cloud registry to support the OCI Specifications 1.1 文章。

可预见的是，各大云厂商的镜像仓库都会跟进这一标准，安全供应链以及容器镜像加速的增值服务也会因此得到大面积推广。而作为容器镜像的消费端，为了支持这一特性，containerd 社区的想法是引入组合型插件 Image Transfer Service，将镜像分发和打包处理都抽象成数据流的转发，并统一收编在服务端处理。

Pull 需要新的抽象

在 containerd 1.7 版本之前，镜像数据处理的绝大部分操作都集中在客户端。containerd 设计偏向于把服务端做薄，服务端仅做底层资源的 CRUD；而客户端则采用类似 Backends For Frontend 理念来为复杂流程封装接口，如下图所示 Pull 镜像的函数接口。下载镜像涉及到镜像地址解析、密钥管理、并发下载以及解压处理，但该流程仅适用于下载标准格式的镜像，任何调整都容易产生不适。

NOTE: containerd CRI 插件属于 containerd 进程的一部分，因此 CRI 插件在使用 Pull 函数接口时，镜像数据在 content/diff/snapshotter service 之间传递不走 grpc 协议，仅是内部函数调用。

让我们来简单回顾下当初 containerd 是如何支持容器镜像 lazy-loading 特性。

由于容器镜像打包采用了不可检索的 tar 格式，因此目前市面上开源的镜像 lazy-loading 方案都涉及到镜像格式的改造，比如阿里云基于块设备的 overlaybd、蚂蚁金服基于文件系统的 nydus，以及 containerd 社区基于可检索 gzip 构建的 stargz。而格式的变化意味着 tar 解压流程不适合这类镜像(上图里的 apply diff 阶段)，为了适配这一特性，containerd 在 GA 之后首次修改了 snapshotter 元数据的管理逻辑 Support target snapshot references on prepare：即在解压镜像时，它会告知 snapshotter 插件这是为解压镜像而准备的可写层。

容器镜像的制作过程大多都是将容器的可写层提交成镜像的只读层，因此 containerd snapshotter 实现里并不会区分可写层是为谁准备的。而上述特性可以让 lazy-loading snapshotter 感知到这是在下镜像阶段，它可以通过返回 已存在 错误来告知客户端：该镜像层已经下载并解压过了，请处理下一层吧。在不大改流程的情况下，这也算是支持 lazy-loading 特性。

但这种方案仅支持匿名用户访问的镜像。基于安全的考虑，下镜像过程并不会将用户密钥信息传递给 snapshotter；而 lazy-loading 需要时刻保证数据可访问，否则业务容器在读取 rootfs 时将会出现 IO 阻塞。直到目前为止，containerd 社区依旧在讨论如何管理用户密钥信息: Enable remote snapshotter to receive creds from containerd CRI plugin。除此之外，容器镜像 lazy-loading 特性还要求用户手动替换或者集群管理员通过 webhook 来修改 pod 里的镜像信息。从产品侧的角度看，这种端到端的集成体验极差。

安全供应链相关的特性也面临相同问题：Datadog 开发者提出 Plugin to CRI for image digest verification，他们希望 containerd 能在下载镜像阶段进行镜像校验，而不是在集群的 webhook 里。但目前的 Pull 流程是无法感知镜像的辅助信息，更谈不上校验。考虑到镜像辅助信息的多样性，Pull 函数接口的 Optional 配置方法无法满足插件化需求。

Image Transfer Service

镜像数据的来源可以是镜像仓库、本地镜像 tar.gz 或者是本地解压后的存储等。不同的来源之间可以相互流动，比如下载流程可以理解成 镜像仓库 -> 本地对象存储 (containerd content service) -> 本地解压后的存储 (containerd snapshot service)，相反的流转将变成上传镜像；甚至还可以通过简单的数据转发，实现镜像在不同仓库之间迁移。containerd 通过引入 Image Transfer service 来将 Pull/Push 抽象成数据迁移流程，而 transfer service 本身是插件化的，在相同数据流向的情况下，containerd 支持定制化开发。

type Transferer interface {
	Transfer(ctx context.Context, 
	    source interface{},
		destination interface{},
		opts ...Opt，
	) error
}

如上图所示，Transfer objects 代表着数据源，数据流向是 Registry 到 Image Store，目前已在 1.7 版本里支持的迁移能力如下表所示。其中数据转发过程可能会和客户端交互，比如推送当前的传输状态，或者客户端提供密钥信息做鉴权等等。这些交互过程都通过 streaming service 来实现: 客户端在发起数据传输时，它会向 streaming service 申请数据交互通道，这些通道将会共享给 Transfer object，并由具体的 Transfer object 实现来决定如何交互。

Source	Destination	Description
Registry	Image Store	“pull”
Image Store	Registry	“push”
Object stream (Archive)	Image Store	“import”
Image Store	Object stream (Archive)	“export”
Image Store	Image Store	“tag”

对于 lazy-loading 和安全供应链场景，镜像的数据流向应该如下表所示。在后续的实现里，fetch 操作将会负责拉取镜像相关的 referrers，并在目标数据源中做相应的处理，比如安全供应链的数据源会校验数据的合法性，而 lazy-loading 场景下的关注点将会是 如何通过 referrers 来获得真正的镜像格式，后续的进展可以关注 OCI Referrers API support。

Source	Destination	Description
Registry	Content Store(Object Stream)	“fetch”
Content Store(Object Stream)	Mount/Snapshot	“unpack”
Content Store(Object Stream)	Image Store	“tag”

除此之外，镜像的密钥管理也将会插件化，只是现在如何同 lazy-loading snapshotter 交互还未确定，后续的进展可以关注 [transfer] credential manager plugin。

统一镜像处理逻辑

虽然 containerd CRI 插件使用了 Pull 函数方法来处理镜像下载，但是它有不少优化特性，比如可根据流量来自动取消下载 feature: support image pull progress timeout，通过共享机制来避免重复下载 CRI: improve image pulling performance，或者是优化 lazy-loading snapshotter 集成体验 Export remote snapshotter label handler 等。这些处理在 nerdctl 也有类似的实现，transfer service 的出现可以很好的统一类似的处理逻辑。

需要说明的是，transfer service 出现并不意味着放弃客户端下载的支持，类似 buildkit 这样项目有自身镜像管理需求，transfer service 不一定适合它们，这些项目依旧会使用 containerd 提供的 Pull 函数接口。

把镜像下载到虚拟机里？？

有部分厂家会使用机密计算和普通安全容器来提供多住户的 Kubernetes 产品，为了保证容器数据安全，这些场景有在 Guest OS 内下镜像的需求。为了支持这一特性，containerd ttrpc 支持了 streaming 能力 Introduce streaming。配合上 transfer service，containerd 2.0 大概率会把下载请求转发给 Guest OS 内的控制器，如下图所示。这部分转发逻辑也还在设计阶段，预计会在 Sandbox API 定稿后出提供。

最后

个人一直很喜欢 containerd 插件机制，所以整体下来会比较期待 transfer service 在插件管理上的演进。

这一篇就先这样吧，有问题欢迎私信。

下一篇打算聊一下 containerd 垃圾回收机制。

containerd 1.7: UserNamespace Stateless Pod

Sat, 04 Mar 2023 15:20:45 +0800

containerd 1.7 版本有比较多的实验特性。在这里，我会介绍 containerd 对 UserNamespace Stateless Pod 支持的情况，算是个人对 containerd 1.7 版本特性介绍系列的开篇。

1. UserNamespace 安全特性

Linux 内核是基于进程的 credentials(7) 凭证来做访问控制，比如进程的拥有者标识 UID/GID 和用于系统资源访问控制判定的 Effective UID/GID 等凭证。而 user_namespace(7) 提供了安全隔离特性。在不同的 user namespace(userns) 下，同一个进程不仅有不同的 UID/GID，同时还具备了不同的 capabilities(7) 权限。比如 u1001 用户进程 bash 通过 unshare -r bash 进入到了新的 userns，并将自己映射成了 root 用户，还具备了所有的 capabilities。但这个进程真的就变成了特权进程？这取决于该用户在系统资源所属的 userns 里是否拥有访问权限。

在介绍具体的判定规则前，先花点时间了解下内核是如何管理 UID/GID 的映射关系。

每个进程都必须归属于某一个 userns。在初始状态下，进程都属于 initial userns。Initial userns 比较特殊，它没有任何映射关系；Linux 支持嵌套的 userns，所有正在使用的 userns 组成的关系图将会是以 initial userns 为根的树状图。在 parent userns 里的进程，只要具备 CAP_SET{UID,GID} 能力，这些进程就可以通过 /proc/[pid]/{uid,gid}_map 文件接口，以 ID-inside-ns ID-outside-ns Range-length 的格式，给刚进入 child userns 的进程设置 UID/GID 映射关系，而创建该 userns 进程的 Effective UID(EUID) 将成为 userns 的所有者，如下图所示。

在上图中，有两层 userns 映射关系：

uid_map: 0 1001 10 将 initial userns 的 UID [1001, 1010] 映射到 userns X 里的 UID [0, 9]
uid_map: 10 0 5 将 userns X 中的 UID [0, 4] 映射成 userns Y 里的 UID [10, 14]。

但这些都是用户态的映射关系，uid_map 文件接口会将其转化成内核态的映射关系 userspace-id:kernel-id:range(u:k:r)，比如 u1000:k0:r100 映射关系可以把 k10 映射成 u1010 = k10 - k0 + u1000；同样的，u1005 可以转化为 k5 = u1005 - u1000 + k0，其中 r100 是用来判断映射是否超出范围。Initial userns 的 ID 映射关系是 u0:k0:r4294967295，相当于 u 等于 k。Userns X 的 parent userns 是 initial userns，结合 uid_map 的配置，内核态的映射关系应为 u0:k1001:r10；同理 Userns Y 的内核态映射关系是 u10:k1001:r5。在进行权限判断时，内核最终都以 kernel-id 为凭据。

回到最初的话题，为什么具备了所有 capabilities 还是不能进行 bind-mount？

Linux 的系统资源都归属于某一个 userns，比如 mount_namespace(7) 下的挂载资源，network_namespace(7) 下的设备资源等等。当进程想要访问系统资源时，内核会采用下面的策略来决定进程是否有权 (为了方便解释，被访问的系统资源属于 userns X，而访问该系统资源的进程属于 userns Y)：

在 initial userns 为根的树状关系里，当 userns X 是 userns Y 的祖先或者是兄弟分支，进程无权访问；
当 userns X 与 userns Y 相等或者 userns Y 是 userns X 的祖先时，只要进程具备资源要求的 capabilities 即可访问；
当 userns Y 是 userns X 的父节点，且当前进程的 EUID 为 userns X 的创建者，那么该进程可以访问 userns Y 下的所有系统资源。

判断进程的 EUID 是否为 userns X 的所有者时，内核比较的是 kernel-id。上诉的判断来自 cap_capable 函数。大部分的权限判断都包着它来做，比如挂载权限的判断逻辑在 may_mount 等，感兴趣的可以去看看。

如上图所示，虽然 unshare 切换了 userns，但 mount_namespace(mountns) 依然属于 parent userns。根据访问策略来看，当前进程无权访问祖先 userns 的资源，因此挂载失败。如果想要在不提权的情况下进行挂载，最好的方式就是 unshare 切换新的 mountns。全新的 mountns 将属于当前的 userns；当前进程具有 SYS_ADMIN 权限，所以它能进行挂载。

现在的容器默认会配置独立的 mount/network/pid/ipc/uts_namespace(7) 资源，没有的独立的 userns，这些系统资源依旧隶属于 initial userns。而大部分容器进程都以 root 用户身份启动，为了防止容器进程逃逸后对系统造成破坏，业界的普遍做法是限制容器进程的 capabilities，同时采用 SELinux/Apparmor 安全规则控制对系统资源的访问。但这毕竟都是后验形式，集群管理员需要对容器进程做大量的行为审计，他们才能得到有效的安全规则。但就目前的结果来看，现在依然有不少 initial userns 的权限泄漏所引发的安全问题。

既然全新的 userns 可以完全禁止进程访问隶属于 initial userns 的系统资源，那么为什么迟迟不落地呢？

2. FSUID 映射问题

在 Linux 系统里，一个进程有两个关键的身份凭证：一个是前面提到的 EUID，它用于做系统资源的权限判断；而另外一个是 Filesystem UID(FSUID)，它用来判断是否有权限访问文件目录。一般情况下只要不调用 setfsuid，进程的 FSUID 都和 EUID 保持一致。

当进程在创建文件目录时，文件系统会将当前进程 FSUID 的映射结果写入到存储设备。当然，文件系统并不是持久化当前 userns 的映射结果。当进程挂载文件系统时，内核会将该进程所在的 userns caller u:k:r 映射关系作为对应文件系统的 fs u:k:r 映射关系。文件系统会将创建文件进程的 FSUID kernel-id 转化成 fs u:k:r 下的 userspace-id，这个 id 才是最终存储的结果。有了这个概念后，我们看下查看文件拥有者标识的过程。

假设用户 u1001 HOME 目录所在的文件系统采用了 fs u0:k0:r4294967295 映射，以及当前 stat 进程的 userns 也采用了同样的映射 caller u0:k0:r4294967295。文件系统先将存储设备里的 u1001 转化成 k1001，内核再通过当前进程的映射关系转化，最终得到我们所看到的 u1001。

让我们再看看把 u1001 映射成 root 用户后的显示效果，如下图所示。因为进程已经切换到了新的 userns，但 .bashrc 文件的存储没有发生变化，经过两次映射，我们最终看到的是 u0。原先 /var/lib/containerd 在存储设备里的 FSUID 是 u0，经过 fs u0:k0:r4294967295 映射后得到 k0，但 k0 并不在 caller u0:k1001:r1 的范围内。对于这些不在映射范围内的 UID，内核统一显示成 nobody(65534)。这也意味着，当前 root 用户依然无法访问 /var/lib/containerd。

回到容器的使用场景。首先，绝大多数的容器镜像是以 root 用户构建，这就要求容器进程的 FSUID 经过映射后要和存储对应的 FSUID 一致。为了方便解释，这里假设容器镜像的底层文件系统采用 initial userns 映射方式。如果容器进程采用 caller r0:k1001:r1 映射，那么它是无权访问镜像内容，它将无法启动。解决这个问题的方式，就是在启动容器前，我们通过 chown -R 把容器的根录都修改成 u1001。但这也意味着效率低下。

Image	Size	Inodes	overlayfs w/ metacopy	overlayfs w/o metacopy
tensorflow/tensorflow:latest	1489MiB	32596	1.29s	54.80s
library/node:latest	1425MiB	33385	1.18s	52.86s
library/ubuntu:22.04	83.4MiB	3517	0.15s	5.32s

当我们在修改容器根目录的文件属性时，如果没有 metacopy=on 的属性支持，那么 chown -R 在修改文件属性前，overlayfs 文件系统会将这个文件从只读层拷贝到可写层。如果文件越大，整个修改过程就越慢，同时还产生磁盘压力；带上 metacopy=on 之后，至少 overlayfs 仅拷贝文件的 metadata，效率高不少。但面对小文件特别多的场景，chown -R 操作依旧很耗时。与此同时， chown 还是永久性修改文件属性。

然而不同容器之间可能会共享同一个数据卷。常见的场景有：容器 A 以 caller r0:k1001:r1 映射关系产生数据，然后容器 B 再进行分析消费。这就要求容器 B 也必须使用 r0:k1001:r1 映射关系，否则只能再次使用 chown 来切换。

在全民白嫖镜像仓库的形势下，镜像仓库已经变成 免费数据 仓库。个人见过上百 GiB 的容器镜像，在这种容器镜像面前使用 chown，这简直是劝退。

3. Mount idmapped 特性 >= kernel v5.12

为了解决这个映射的难题，Linux v5.12 版本引入了挂载点的映射关系 mount u:k:r，用户可以通过它来绕过文件系统原先的 fs u:k:r 映射，其中该特性由 mount_setattr(2) 系统调用提供。我们直接看例子解释吧，如下图所示。

mount-idmapped 工具把 /var/lib/containerd 挂载到 /mnt 下，并通过 mount u0:k1001:r1 映射关系将其 授权 给 u1001 用户进程访问，u1001 用户无需提权就可以在 /mnt 下访问 /var/lib/containerd 的数据。挂载点 /mnt 上的 mount u0:k1001:r1 映射关系是替代了原先的 fs u0:k0:r4294967295。只是底层文件系统 inode 保存的是 fs u:k:r 映射后的 kernel-id；而 mount u:k:r 由 Virtual filesystem(vfs) 模块管理，vfs 拿不到存储设备上保存的 userspace-id，所以 vfs 需要利用 fs u:k:r 转化回来。这也就是上图里，u0 -> k0 -> u0 转化看似无效，但它其实是真实的处理流程。

如果 u1001 用户进程在 /mnt 目录里进行写操作，通过上图的映射关系，新文件的 FSUID 最终将以 u0 落盘。

无论多大的文件目录，该内核特性都可以很快完成 FSUID 映射，还可以同时支持多个 mount u:k:r 映射，也解决了数据卷共享问题。我想这就是为什么社区开始推进 userns 落地的原因吧。

4. containerd 目前的集成情况

为了支持 userns，containerd 对 CRI RunPodSandbox 的流程有比较大的改动，但这仅针对 userns 场景的 Pod，其他场景和之前保持一致。

4.1 依旧使用 chown 修改容器根目录

containerd 并没有使用 mount_setattr 特性，目前还是使用 chown 的形式。为了减少不必要的 chown 操作，containerd 将首次 chown 之后的容器根目录做成只读 snapshot，而对于后续使用相同镜像以及相同 uid_map 的容器而言，containerd 可以直接用现成的 snapshot 做根目录。也算是一个优化吧。

没有集成 mount idmapped 的主要原因在于，它对 containerd 现有的 mount 挂载流程影响比较大。

Linux v5.19 overlayfs 文件系统开始支持 mount idmapped，但它是针对只读层设计，用户无法对一个已挂载好的 overlayfs 文件系统进行 mount idmapped，毕竟 overlayfs 并没有像 ext4/xfs/btrfs 那样拥有 FS_ALLOW_IDMAP。

// https://elixir.bootlin.com/linux/v6.1.15/source/fs/namespace.c#L3979
static int can_idmap_mount(const struct mount_kattr *kattr, struct mount *mnt)
{
	...

	/* The underlying filesystem doesn't support idmapped mounts yet. */
	if (!(m->mnt_sb->s_type->fs_flags & FS_ALLOW_IDMAP))
		return -EINVAL;
    
    ...
}

为此，我们需要将容器镜像的只读层挨个进行 mount idmapped，最后再挂载成 overlayfs。或者是将容器镜像直接解压到已经 mount idmapped 好的挂载点上。但后者对现有 containerd snapshot 管理有比较大的冲击，前者看起来会更容易落地些。

值得一提的是，新版本内核已经演进出了新的 mount API: fsopen(2)/fsconfig(2)/fsmount(2) 将文件系统挂载拆成多次系统调用，而且 fsmount(2) 仅是生成 anonymous mount 记录，需要 move_mount(2) 将其转化成可见的挂载点。而普通的 bind mount 将由 open_tree(2) 来产生 anonymouns mount。

mount_setattr 有一个要求就是必须是 anonymouns mount。但除了 fsopen，fsconfig/fsmount/open_tree 都没进入 golang.org/x/sys/unix。整体来看，mount_setattr 在 containerd 上落下来可能还需要几个月的时间。

4.2 延后网络初始化

早期 dockerd 的容器网络初始化是在 runC 进入 init 阶段后，runC 通过 prestart_hook 回调通知 dockerd， dockerd 再通过 setns(2) 进入到容器 network namespace(netns) 进行配置。

同样，kubelet 在处理 dockershim 的网络时，它也是等待 pause 容器启动后，并通过 /proc/[pause-pid]/ns/net 来进行 CNI 调用。但这里有一个很大的问题就是，一旦 pause 容器进程被意外杀死，同时原先 pause 容器进程 pid 被复用，那么 CNI 将会在错误的 netns 里进行操作。运气不好的话，CNI 可能会操作到 initial userns 下的 netns，造成整机的网络中断。

而 containerd CRI 当前的设计可以避免 pid 复用所引发的问题。在启动 pause 容器前，containerd 会提前准备好 netns，并将其持久化到 /run/netns 之下。这个行为和 ip netns add 行为一致，如下图所示。CNI 初始化完毕后，containerd 才将持久化后的 netns 地址交给 runC。这完全避免了 pid 复用的问题。

但这个不适用于 userns 场景，因为 containerd 创建的出来 netns 属于 initial userns，而且它还挂载在属于 initial userns 的 mountns 里。新的 userns 无法操作 netns 下的资源，同时因为 netns 归属问题，还导致 runC 无法将 /sys/ 挂载容器根目录。

解决这个问题的唯一途径就是让 runC 创建 netns。为了防止出现 pid 复用问题，在 runC init 阶段结束后，containerd 将 /proc/[pause-pid]/ns/net 持久化到 /run/netns 之下，然后再判断 runC init 进程是否还处于运行状态，避免出现 datarace 的情况。

为了避免对现有容器运行时集成的影响，这个处理逻辑仅针对使用 userns 的容器，原先支持的场景不受影响。

5. 最后

目前该特性距离上生产还有很长的路要走，下图是 Kubernetes SIG-Node 之前讨论过规划。除此之外，还得看用户侧是否实时跟进新内核，以及各大 Linux 发行版商是否会及时 backport 新版本特性。

个人倒是很喜欢这个特性，因为 userns 几乎可以让容器进程更好地享受隔离特性，减少 seccomp 这些作用不大但影响性能的配置干扰。说到这，我想起前同事做过的镜像构建项目，因为安全问题，管理员迟迟不愿意开放 mount 挂载权限。如果这个特性能推广，应该能减少很多不必要的会了吧。。。

使用 unshare(CLONE_FS) 来优化 OverlayFS 挂载

Sat, 15 Oct 2022 18:20:45 +0800

背景

在 Linux 平台上，大部分情况下会使用 OverlayFS 文件系统来管理容器镜像存储，而 OverlayFS 文件的特点也比较符合容器场景使用：它不仅可以将多个目录合并成统一的访问视图，还能做到读写分离。

mount -t overlay overlay \
  -olowerdir=/lower1:/lower2:/lower3,upperdir=/upper,workdir=/work \
  /merged

如上面的挂载命令所示， lowerdir 代表着容器镜像层解压后的目录。从 OCI Image 标准定义来看，容器镜像的层数并没有限制。但 mount(2) 系统调用的参数被严格限制在 4KiB，所以实际使用的容器镜像层级有限制的。

为了解决这个层级的问题，Docker 采用压缩 lowerdir 参数来尽可能地支持更多层级的容器镜像。Docker 存储插件使用 l/${random-id(len=26)} 软链接指向实际的存储目录，然后跳到 /var/lib/docker/overlay2 目录下进行挂载，这样就不需要在 lowerdir 参数里重复填写 /var/lib/docker/overlay2/ 这 25 个字符。按照 Docker 代码里的注释，Overlay 镜像存储最大可支持到 128 层。

/var/lib/docker/overlay2/l/63WSQBTYICXV2O7SOZXAXYLAY2 
  -> ../f98d68377b05c44bacc062397f7ebaaf066b070fce15fbcfe824698d15f2eaa8/diff

但在当时，Go 并没有提供太多的线程操作，所有被 Go-Runtime 管理的线程都使用了 CLONE_FS。一旦某个 Goroutine 通过 Chdir 修改了当前工作目录，这会污染到整个进程，Docker 无法基于这样的方式来并发处理 OverlayFS 挂载请求，所以在当时只能选择 Fork-Exec 子进程来处理。考虑到维护多个二进制的成本过高，Docker 采用了 Re-exec 的方式。

不管怎么样，Fork-Exec 处理挂载成本很高，而且这样挂载逻辑没法独立成一个 Go Package，它要求使用者在 Go-Main-Init 函数里添加启动的预处理逻辑。所以在 containerd 项目里，我们采用了 Clone-Thread 的形式。

这个 Patch 是 Derek 带着我做的，也算是我给 containerd 提交的第一个有意思的修改。当时我们模拟了 Go-Exec-Fork 进程的步骤来创建线程。但毕竟这个线程的状态并不能用于其他 Goroutine，所以我们会锁住这个线程，这个线程在处理完 Chdir 和 mount 之后就主动退出，避免对整个进程的影响。当然这种模拟 Go-Exec-Fork 进程的行为不只有我们这么做，gVisor 也这么玩：）

//go:linkname beforeFork syscall.runtime_BeforeFork
func beforeFork()

//go:linkname afterFork syscall.runtime_AfterFork
func afterFork()

//go:linkname afterForkInChild syscall.runtime_AfterForkInChild
func afterForkInChild()

模拟 Go-Exec-Fork 来管理线程在 containerd 平稳运行了近 5 年，但最近社区的 Brian Goff 和 Cory Snider 发现还有更好的处理方式。

Unshare(CLONE_FS)

https://man7.org/linux/man-pages/man2/unshare.2.html

CLONE_FS
              Reverse the effect of the clone(2) CLONE_FS flag.  Unshare
              filesystem attributes, so that the calling process no
              longer shares its root directory (chroot(2)), current
              directory (chdir(2)), or umask (umask(2)) attributes with
              any other process.

根据 unshare(2) 的文档来看，CLONE_FS 只提到了进程。但通过实践来看，它是可以作用在单个线程上。如下面的代码所示，syscall.Unshare(CLONE_FS) 之后修改当前工作目录并不会对其他线程造成影响。

➜  /tmp cat main.go
package main

import (
        "fmt"
        "os"
        "runtime"
        "syscall"
)

func main() {
        ch := make(chan struct{})
        go func() {
                runtime.LockOSThread()
                defer close(ch)

                syscall.Unshare(syscall.CLONE_FS)
                syscall.Chdir("/etc")

                fmt.Println(os.Getwd())
        }()
        <-ch
        fmt.Println(os.Getwd())
}

➜  /tmp go run main.go
/etc <nil>
/tmp <nil>

unshare 提供了对 Go 管理线程改造的能力，再配合上 runtime.LockOSThread 锁线程的能力，基本上就可以 Go 来做一些更底层的操作了。理论上来说，Replace mount fork hack with CLONE_FS 是比前面模拟 Go-Fork-Exec 逻辑更优秀的解法。而且除此之外，unshare(CLONE_FS) 还支持 chroot, umask 等系统调用，这无疑是给容器相关的编程带来了很大便利。

但目前这个优化并没有在 containerd 社区合并，原因是我们发现 Go-Runtime 自身的问题。

后续跟进

首先，Go-Runtime 的 LockOSThread 文档没有提及 Main-Thread 的特殊性。在 Linux Kernel 里，Main Thread 其实就是我们平时提到的进程；当它被 LockOSThread 了但没有被 Unlock，按照官方文档说明，这个线程会主动退出。但实际上 Main-Thread 一旦推出，整个进程就变成僵尸状态，也就是退出了，所以 Go-Runtime 并不会退出这个线程，只是将其变成不可调度状态。

其实，在 Github Action Pipeline 里，我们发现 Go-Runtime 自身处理锁的时候有问题，也不知道是不是和 Main-Thread 没有退出有关导致。比较麻烦的是，每次出现的错误都不一样。

https://github.com/fuweid/containerd-pr-7513/actions/runs/3255360436/jobs/5345228547

runtime: newstack at runtime.checkdead+0x2f5 sp=0x7fb781e8ae38 stack=[0xc00004c800, 0xc00004d000]
	morebuf={pc:0x4745df sp:0x7fb781e8ae40 lr:0x0}
	sched={pc:0x47c975 sp:0x7fb781e8ae38 lr:0x0 ctxt:0x0}
runtime.mexit(0x1)
	/opt/hostedtoolcache/go/1.19.2/x64/src/runtime/proc.go:1545 +0x17f fp=0x7fb781e8ae70 sp=0x7fb781e8ae40 pc=0x4[74](https://github.com/fuweid/containerd-pr-7513/actions/runs/3255360436/jobs/5345228547#step:5:75)5df
runtime.mstart0()
	/opt/hostedtoolcache/go/1.19.2/x64/src/runtime/proc.go:1391 +0x89 fp=0x7fb781e8aea0 sp=0x7fb781e8ae70 pc=0x474289
runtime.mstart()
	/opt/hostedtoolcache/go/1.19.2/x64/src/runtime/asm_amd64.s:390 +0x5 fp=0x7fb781e8aea8 sp=0x7fb781e8aea0 pc=0x4a2725
created by github.com/fuweid/containerd-pr-[75](https://github.com/fuweid/containerd-pr-7513/actions/runs/3255360436/jobs/5345228547#step:5:76)13.mountAt
	/home/runner/work/containerd-pr-7513/containerd-pr-7513/mount.go:126 +0x2ac
fatal error: runtime: stack split at bad time

具体问题描述都在 runtime: “runtime·lock: lock count” fatal error when cgo is enabled，感兴趣的朋友可以关注下这个问题。

eBPF 动态观测之指令跳板

Sun, 12 Jun 2022 12:00:53 +0800

在 containerd 自定义插件 embedshim 项目里，我借助了 Linux 内核里的 trace_sched_process_exit 观测能力，并利用 eBPF Map 记录和持久化容器进程退出事件。这类观测能力依赖内核在关键代码路径上提前定义好钩子，它属于静态观测技术，任何变化都需要重新编译 Linux 内核。如果我们想观测内核中的某一个关键函数或者某一行关键代码时，我们可以选择 kprobe 或者 ftrace 这类动态观测技术。

kprobe - single-step

Kernel Probe(kprobe) 是一个轻量级内核指令观测的技术，用户可以指定观测内核的某一个函数，甚至可以观测函数内的某一条指令，除了 kprobe 框架自身的代码以及异常处理函数外，用户几乎可以观测内核运行的每一条指令。

当 CPU 执行到被观测指令时，也就是产生了一次 观测事件，那么 kprobe 会把当前 CPU 的寄存器信息作为输入去执行用户注册的观测程序。然而被观测的指令由用户随机指定，考虑到性能问题，kprobe 无法在编译内核时为每一条指令预留埋点，同时我们很难在编译好的程序里动态插入指令。基于性能和稳定性考虑，kprobe 选择了 单步调试 的通用方案。

在介绍 kprobe 方案之前，我们先简单回顾下 gdb 调试过程。为了调试某一行代码，我们先通过 breakpoint 给该行打上断点，当程序运行到该行代码时就会停下来，等待我们的下一步交互。这个时候我们就可以通过 p 或者 info 等命令来查看当前程序的状态，甚至我们还可以通过 单步调试 来观察程序每条指令带来的变化。我们利用断点和单步调试产生的停顿来观测程序，这本质上也是一种埋点，内核也正是通过这种方式来实现 kprobe，如下图所示。

x86_64 CPU 架构下的断点指令为 INT3，它是一个单字节指令 0xcc 。我们可以用 INT3 来替换任何指令的 opcode，被替换的指令（以及后续指令）都将被中断所短路掉，而 CPU 将进入 do_int3 [1] 中断处理逻辑。

如上图所示，kprobe 观测的是 Near CALL wq_worker_running 指令。在观测之前，kprobe 申请新的空间 copy-ip-addr 来存储被观测指令的内容 e8 fc 57 77 ff，然后调用 arch_arm_kprobe/text_poke [2] 将 Near CALL 0xe8 替换成 INT3 0xcc。打完断点后，一旦有 CPU 执行到这条指令上，那 CPU 必然会进入到 INT3 中断处理逻辑里的 do_int3/kprobe_int3_handler [3]。

在 kprobe_int3_handler 中断逻辑里，kprobe 首先会标记当前 CPU 为 KPROBE_HIT_ACTIVE 状态，表明该 CPU 正在处理 kprobe 的观测事件。而通过内核模块或者 eBPF 系统调用注册的观测程序，它们都被聚合到 pre_handler 钩子函数内，kprobe_int3_handler 会先执行这些观测程序，再去运行观测的指令。

在执行被观测的指令时，内核并不会将 INT3 还原成 Near CALL，毕竟还会有其他 CPU 可能会触发该指令的观测事件，因此该 CPU 需要跳到 copy-ip-addr 指令地址上运行原先的指令。 copy-ip-addr 仅保存一条指令，Near CALL 返回的指令地址依然在原先指令 orig-ip-addr 地址之后；加上 Near CALL 返回指令地址以及下一条指令地址的计算都是基于当前指令地址计算出来的，该 CPU 需要一个修正指令地址和返回指令地址的机会，而这个机会由 单步调试 所产生的中断来提供。

首先 kprobe 会将 CPU 状态切换成 KPROBE_HIT_SS，表明 CPU 正在准备单步调试状态。内核会将寄存器中的 EIP 指向 copy-ip-addr，并配置 X86_EFLAGS_TF 标记，这个标记会让 CPU 执行完一条指令后产生调试中断，保证 CPU 会进入 do_debug/kprobe_debug_handler [4] 中断函数。当进入 kprobe_debug_handler 中断处理后，CPU 的下一条执行指令地址变成了 copy-ip-addr + 5 + fc 57 77 ff，其中 copy-ip-addr + 5 表示 copy-ip-addr 的下一条指令地址，因为这个 Near CALL 是五字节指令，而 fc 57 77 ff 表示指令之间的距离。但 fc 57 77 ff 是由 orig-ip-addr + 5 和 wq_worker_running 计算出来的，因此我们需要将其修正成正确的 wq_worker_running 的位置。同理，函数栈里的返回地址也需要更正: return-eip - copy-ip-addr 可获取被观测指令的长度，仅需要将指令长度加到 orig-ip-addr 就可以拿到真正的返回指令地址了。之后 kprobe 将移除 X86_EFFLAGS_TF 标记，取消单步调试状态，并更成 CPU 成 KPROBE_HIT_SSDONE 状态，表明单步调试结束。

NOTE: KPROBE_HIT_XYZ 状态是用来记录当前 kprobe 运行状态。用户自定义程序可能会调用到一个被 kprobe 观测的指令上了，因此在执行 pre/post_handler 时会再次触发 INT3 中断。而 per-CPU 的 kprobe 状态记录可以用来判断当前 INT3 触发是第一次触发 KPROBE_HIT_ACTIVE 还是再次触发 KPROBE_HIT_REENTER。目前 kprobe 仅允许发生一次 KPROBE_HIT_REENTER。

虽然单步执行模式可以让用户观测任何指令，但每条指令都要产生两次中断；如果观测在关键的代码路径上，这种模式势必会影响到内核的性能。 kprobe 针对两次中断共有两个优化方案，我们先来看看 2021 年初的一个优化方案。

kprobe - x86 Insn Emulation

2021 年优化提交名叫 x86/kprobes: Use int3 instead of debug trap for single-step [5]，它是通过离线模拟被观测指令来去除单步调试中断，如下图所示。

我们还是使用 Near CALL 指令的例子来解释。根据 x86_64 IA-32 架构开发文档对 Near CALL 的描述，我们可以将用两条指令来模拟它：

将 Near CALL 的下一条指令 next-ip-addr 地址压入栈，作为函数返回的 return-eip
通过 next-ip-addr 计算出来的指令地址可以直接用 Near JMP 指令跳过去

换言之，Near CALL 指令产生的结果完全可以在 do_int3/kprobe_int3_handler 中断处理中离线模拟出来。在上文提到的单步调试里，do_debug/kprobe_debug_handler 调试中断处理需要通过 resume_execution [6] 里面修正 CPU 的寄存器信息，在我看来，这本质上和模拟没有区别。所以这个方案通过模拟指令的方式来移除了不必要的单步调试中断，这对性能有极大的提升。不过需要说明的是，该方案并非支持所有指令的模拟，根据邮件里的讨论来看，prepare_emulation [7] 模拟的指令足以覆盖大部分场景。

指令模拟优化掉了单步调试中断，但每次观测指令达到时，kprobe 还是会触发 INT3 中断，对关键代码执行路径还是存在影响。

kprobe - detour buffer

Linux 内核社区在 2009 年提出了 kprobe jump optimization [8] 方案，该方案的思路是通过 Near JMP 指令来模拟 do_int3/kprobe_int3_handler 中断处理。该方案在各大发行版里目前默认开启，在当时的优化结果比单步调试快了近 10 倍。虽然它存在一定的局限性，但不妨碍我们了解它，这个方案和后面提到的 ftrace 设计理念一致。

该优化方案通过修改被观测指令成 Near JMP 指令，一旦产生观测事件，CPU 将跳到预定义好的一个代码片段上模拟 kprobe_int3_handler 处理逻辑。但 Near JMP (Rel32) 是一个 五字节 的指令，如果在指令更新过程中，中间结果被其他 CPU 读取执行了，那么将产生不可预知的行为，这甚至会造成内核崩溃。为了保证能安全更新被观测指令，kprobe 还是需要依赖 INT3 中断来协助处理指令更新。

假设我们已经有了模拟 kprobe_int3_handler 的代码片段，为了方便解释，我们将其简称为跳板（虽然方案和文档都称之为 detour buffer，但我觉得跳板更容易理解些）。在这里，我们继续拿之前 Near CALL 的观测指令来举例子。被观测指令 e8 fc 57 77 ff 被 kprobe 更新成 INT3[cc] fc 57 77 ff; 那么任何时刻 CPU 执行这条指令时，它们都会触发 INT3 中断，即使 fc 57 77 ff 这个值被改成非法的值，CPU 也不会使用这个值，INT3 给我们形成了天然的屏障，如下图所示。

kprobe jump 优化方案是一个异步的操作，该方案会触发一个 kworker [9] 来执行被观测指令的更新。那么在指令更新前，CPU 还是可以会触发观测事件，这个时候的处理链路还是会走到 kprobe_int3_handler/setup_singlestep [10]。但它并非使用前面提到的指令模拟，而是直接通过 setup_detour_execution [11] 将寄存器的 EIP 转化成跳板代码指令地址上，相当于模拟了一次更新后的 Near JMP 指令。如果 kworker 开始调用 text_poke_bp [12] ，那么内核会告知所有 CPU，有一个 CPU 当前正在处理指令升级。如果其他 CPU 触发了该指令的 INT3 中断，那么 CPU 将会进入到 poke_int3_handler [13] 中断处理逻辑，同样的它会根据指令来调用不同的模拟逻辑：在 kprobe 指令优化场景下，poke_int3_handler 将会调用 int3_emulate_jmp 模拟逻辑，效果和前面提到的 setup_detour_execution 一致。那么有了 INT3 中断这一屏障后，text_poke_bp 就可以放心更新指令了，其中 text_poke_bp 更新有三步：

指令首地址 opcode 更新成 INT3，确保 poke_int3_handler 能模拟预期的行为；
将指令后半部分更新成预期的值;
将指令的首地址 opcode 更新成预期的值。

text_poke_bp 每一步更新都会同步给所有 CPU，确保它们读到的都是最新的指令内容。

在 kprobe 场景下，最终被观测指令将会变成跳到跳板的指令，而这跳板里的指令内容如上图所示。跳板上的指令由 arch_prepare_optimized_kprobe [14] 代码生成，其中 optimized_callback [15] 用来执行 kprobe 的 pre_handler。跳板指令最后为被观测指令的副本以及跳回到被观测指令的下一指令，其中这个副本并非直接拷贝原来的指令。对于 Near CALL 或者 Near JMP 等具有相对位置的指令，我们需要根据当前跳板和被观测指令之间的差值来更新指令，这样才可以确保被观测指令可以离线运行，原理和单步调试里的 resume_execution 类似。

这个优化效果十分显著，但它对被观测指令有一定的要求。在前面我举的例子里，被观测指令的长度和 Near JMP 指令长度一致，所以被修改的指令仅一条。但在 x86_64 架构里，指令长度是变长编码，常用的指令编码需要的字节少，而不常用的字节多。如果被观测的指令短于五字节，那么指令修改必定涉及到多条。而 text_poke_bp 更新的指令如果跨越了多个指令，那么 INT3 中断将无法保证中间修改的状态不被访问。假设某一条指令可以跳过 INT3 指令访问正在修改的值，那么 CPU 执行时必然会出现不可预知的情况。因此 kprobe 会通过 can_optimize [16] 来扫描被观测指令所在函数的每一条指令，以确保可使用跳板模式来优化。

总的来说，这个优化方案要求被观测指令不能涉及到异常处理、不能出现跳跃到被修改指令的中间位置以及被观测指令是可以脱离原上下文离线运行的。有一定的局限性，但如果我们想要观测某一个函数入口时，我们还是可以使用上这个优化。

kretprobe = kprobe + rethook

kretprobe 提供了观测函数返回时刻 CPU 上下文的能力。

以常用的 Near CALL 为例，我们先回顾下 x86_64 下的函数调用和返回的指令：在函数调用时，CPU 会将返回的指令地址压入栈顶，再执行函数入口处的指令; 当函数返回 (RET 指令）时，CPU 会将栈顶的返回指令地址更新到 EIP 寄存器上，这样 CPU 就可以按照原来的分支继续执行。从出栈入栈的角度看，个人能想到观测函数返回的上下文总有两种方式：

在函数入口处修改返回指令地址，当函数返回时，CPU 就能到我们指定的指令地址上运行，从而完成观测事件的处理；
使用 kprobe 观测函数的返回指令。

第二个方案有一个明显的弊端，注册 kretprobe 的时候需要扫描整个函数的指令。一般函数入口的第一条指令都是可以优化成 Near JMP 指令，无需 INT3 中断。基于这样的假设，kretprobe 选择第一种方式会比较合适，如下图所示（为了方便解释，我使用 x86 kprobe 离线模拟指令的方式来说明）。

首先 kretprobe 会注册一个 kprobe 到函数入口处。这个 kprobe 用来记录当前线程 current 的栈帧 EBP 以及真实返回指令地址 Return-EIP，并修改返回指令地址成 arch_rethook_trampoline 函数。被观测的函数可能没有返回值，也可能递归调用多次，kretprobe 并不会无限制地调用申请 rethook node 来存储上下文，因此用户需要通过配置 maxactive 来决定可以同时处理返回。

在保存 rethook node 信息时，kretprobe 采用入栈的形式保存数据。举一个例子，假设 schedule 函数调用了 wq_worker_running 函数，同时它两都属于 kretprobe 的观测对象。当一个线程调用了 schedule 函数，也走到了 schedule 函数内的 wq_worker_running 函数，那么 kretprobe 在处理返回事件时，第一个处理的应该是 wq_worker_running 的返回时。kretprobe 采用了栈的形式保存 rethook node 信息，有利于 arch_rethook_trampoline 快速地找到正确的 rethook node。

arch_rethook_trampoline [17] 是由一段汇编代码拼成，它主要是用来处理用户注册的观测程序，处理完毕后释放掉 rethook node，并还原成正确的 Return-EIP。

rethook 的概念是近期 x86,rethook,kprobes: Replace kretprobe with rethook on x86 [18] 引入，和早期的 kretprobe-instance 概念作用类似。对于我而言，rethook 更容易理解 kretprobe，毕竟 kretprobe 是通过 kprobe 加入的一种回调钩子，等价于 kprobe + rethook。

fentry/fexit - bpf_trampoline

fentry/fexit 和 kprobe/kretprobe 功能类似，其中 f 表示的是函数，fentry/fexit 分别用来观测函数入口和函数返回的事件。相比于 kprobe，它具有静态观测技术的特点。在高版本的 GCC 里，GCC 提供了 -mentry 选项来为每一个函数入口生成一个埋点函数。为了实现 ftrace 技术，在编译内核会带上这个选项。由于可观测的函数很多，关键路径上频繁调用埋点函数会造成 13% 的性能损失，因此内核在 Link 阶段会将这条 Near CALL 指令替换成 NOP5 指令。

NOP5 指令长度为五个字节，所以对于那些可观测的函数来说，kprobe jump 优化方案肯定是适用的。但 fentry/fexit 采用的并不是 Near JMP，而是 Near CALL。下图展示的是 fentry eBPF 观测程序关联到 do_unlinkat 函数入口处的过程。

首先 bpf_tramp_image_alloc [19] 函数会申请一个页大小的指令内存空间，而这个指令内存空间的地址将有一个符号标记，符号的命名规则为 bpf_trampoline_$key_$index。 key 是通过 BTF ID 来生成，只要关联的函数固定，这个 key 值是固定的; 而 index 是一个自增的 ID，每一次调用 bpf_tracing_prog_attach 函数来关联 eBPF 程序时，它会都 +1。eBPF fentry 并没有 kprobe 那样的 pre_handler 聚合函数，每次关联观测程序都需要重新生成汇编指令，而重新生成的 bpf_tramp_image 将通过新的 index 来做区分。我们可以通过 /proc/kallsyms 来查看这个符号，当然也可以通过符号后的 index 来查看被观测函数的关联次数。

fentry 会通过 arch_prepare_bpf_trampoline [20] 函数在新申请的 bpf_tramp_image 上添加必要的指令：将 do_unlinkat 的函数参数压入栈，然后生成调用已关联的 eBPF 观测程序指令，当然中间还会记录 eBPF 程序调用的耗时，最后会调用 RET 来结束该过程。最后这个 bpf_tramp_image 跳板函数会替换掉 do_unlinkat 函数入口处 NOP5 的指令。替换过程和 kprobe jump 优化一样，同样是通过 text_poke_bp 三步更新模式来替换，最后这个 NOP5 会变成 Near CALL <bpf_tramopline_$key_1>。当然，如果再次添加一个新的 fentry/do_unlinkat 观测程序，那么该指令将从 Near CALL <bpf_trampoline_$key_1> 变成 Near CALL <bpf_tramopline_$key_2>。

对于 fexit 而言，arch_prepare_bpf_trampoline 生成的指令稍微复杂些，但也不难理解，其中唯一的区别在于， do_unlinkat 的调用是发生在 bpf_trampoline_$key_$index 函数体内，而 bpf_trampoline_$key_$index 函数返回后将直接返回到调用 do_unlinkat 的地方。在这里，就不再贴图说明啦，更多细节可以查看 arch_prepare_bpf_trampoline 函数体。

Summary

kprobe 和 fentry/fexit 使用的动态观测技术大同小异，都是通过跳板形式来完成对指令或者函数的观测,都是在开着飞机换引擎。就目前了解的情况来看，fentry eBPF 跳板模式的代码结构和内存使用更简单，没有额外的 kprobe perf_event 数据结构介入。如果内核支持 fentry 的话，我倾向使用 fentry :)。

embedshim: 内核是我的边车

Mon, 02 May 2022 18:20:45 +0800

在 2019 年的时候，当时所在的团队正在开始大规模使用 containerD，我们初期遇到较多 containerd-shim 的死锁等稳定性问题，我们不得不去思考去除 containerd-shim 进程的可能性。由于当时技术选型上的限制，containerd-shim 必须作为容器 subreaper 而存在。直到去年才留意到 pidfd pollable，我才发现 containerd-shim 管控面其实是可以被移除。我顺着这个思路作出了 embedshim 这个 containerD 第三方插件。在介绍这个插件之前，我们先简单回顾下 containerd-shim 的发展历程。

1. 从 docker 的原地升级到 containerd-shim

1.1 原地升级的需求

最初 dockerd 的容器进程管理是非常简单粗暴的，它采用了 Fork-and-Wait 模式来监控容器状态，并通过无名管道接管容器的标准输入输出。如果 dockerd 进程重启，那么它将无法重新监控容器的状态变化，而这些已运行的容器都将变成 孤儿。为了防止资源残留，dockerd 重启后的第一件事就是停掉正在运行的容器。然而节点组件的重启和周期性升级都属于正常操作，dockerd 停服重启应保证正在运行的容器不受影响。

这 docker#2658 帖子记录了当时 dockerd 原地升级的细节讨论；当然除了方案讨论外，用户对该需求落地呼声评论是更强烈些的。组件进程重启涉及到的细节比较多，但可以归类为状态恢复以及临时（残留）数据的清理，比如有讨论清理未完成的网络初始化资源，有讨论如何恢复接管容器的标准输出，还有讨论如何做镜像下载的断点续下等等。而对于本文的主题 - 如何重新接管存量容器进程的场景而言，个人认为仅需要考虑下面两个问题即可：

如何保证容器退出事件不丢失？
如何重新接管容器的标准输入输出？

首先，我们来看第一个问题。进程退出码能正确反映一个进程是以什么状态结束的，有正常退出的，有收到 SIGTERM 信号优雅停服的，还有因无法分配新的内存而被内核 SIGKILL 的。开发者和运维人员可以根据进程退出码以及关键日志信息来做 非预期退出事件 的诊断，所以对于进程管理方案而言，进程退出码必须要能被正确捕获，而当时最稳妥的方式是有一个常驻进程来做容器进程的 subreaper。

相比于第一个问题，第二个问题处理起来要简单些。经历过早期节点运维的朋友都知道，在容器化之前呢，大部分业务进程的管理是通过 systemd-service 来实现。业务进程直接被一号进程所监管，同时它们采用了 Headless 无界面无交互的方式运行。它们的标准输出通常以 UDS 流的形式传递给 systemd-journald 服务，由 systemd-journald 来做日志持久化和轮动存储。

容器化后的节点运维比 systemd 模式要稍微复杂些。容器化产生了根路经和资源视图隔离，容器管理面需要封装 nsenter 和 chroot/pivot 等系统调用来提供便捷的运维通道。dockerd 进程提供了 execCreate/execStart/execAttach HTTP 接口来进入到容器隔离视图，这种具有交互能力的运维通道必定会感知 dockerd 停服。但个人认为这种感知是可接受的，只要能保证容器标准输出不因 dockerd 停服而丢失即可。在标准输入输出的接管上，dockerd 并没有采用 UDS 流模式，而是采用有名管道的方式。

一般情况下，systemd-journald 服务会备份 UDS 通信的文件句柄在一号进程那，否则 systemd-journald 重启将自动关闭 UDS 通信管道，业务进程将收到 SIGPIPE 错误，该通信管道将无法接受数据，只能通过重启业务进程来解决问题。但 dockerd 进程没有这样的福利，它只能选择通信管道可文件实体化的有名管道。只要数据产生者以 读写模式 开启有名管道，即使作为接收端的 dockerd 停服了也不会产生 SIGPIPE 错误，最差也就是停服时间长导致业务进程阻塞（systemd-journald 同样有该问题）。

所以回到最初的问题上，dockerd 需要一个常驻进程来做容器进程的 subreaper。

1.2 live-restore： containerd-shim 的雏形

从 2013 年到 2016 年期间，docker 社区先后将 libcontainer(runC) 实现捐赠给 OCI 以及 libcontainerd 组件进程化，这些里程碑的出现推动了 docker 原地升级的落地，并在 2016 年的 v1.12 大版本里推出了 live-restore: true 原地升级的能力。

如上图所示，docker-containerd-shim(后称 shim) 将作为容器进程的父进程，它仅用于转发容器的标准输入输出和监控容器状态变化。由于 shim 功能单一，它编译后仅有 2 MB 左右。如果容器数目不多，而且没有过多的数据转发给 dockerd，节点上的 shim 进程消耗资源属于可控的状态。至于这里为什么会多一个 docker-containerd 进程，个人猜测这和后续捐赠动作有关，docker-containerd 后续将会成为独立项目 containerD 并捐赠给 CNCF 基金会;而 containerD 的定位是 an industry-standard container runtime，开发者可以根据自己的需要来定制容器管控面，比如早期的 containerd-CRI 组件，buildkitd 镜像构建服务以及阿里巴巴的 PouchContainer 引擎等等，所以 v1.12 大版本把 dockerd 拆成三层管控，个人理解这是为了方便后续的集成。

docker v1.12 版本是一个重要的里程碑，它的出现基本上预示着容器技术将会在生产环境的大规模使用。当时 docker 社区的版本里称之为 Deamonless Container，即不需要常驻进程来管理容器。其实阿，这里的 Deamonless 指的是 dockerd。

1.3 CNCF 版本的 containerd-shim

到了 2017 年，docker 将 docker-containerd 组件捐赠给了 CNCF 基金会，并以 containerD(Con-tay-ner-D) 全新的项目出现。从个人角度来看，containerD 是 OCI 镜像格式标准、镜像分发标准以及容器运行时管控的最佳实践。containerD 目标是成为一个工业级别的容器引擎，可用它来对接任何自定义的管控需求：向上可以对接 Kubernetes Container Runtime Interface(CRI) 和构建镜像的 buildkitd；对下可以管理 Kata-Container, gVisor, Windows-Container 等不同的容器运行时。

但在 containerD 项目初期，容器生命周期管控逻辑集中在 containerD 进程里。为了对接不同的容器运行时，containerD 将管控逻辑下沉到 shim 实现上，如下图所示。容器运行时的作者仅需要实现 shim 接口就可以和 containerD 做第三方插件的集成。

除了插件化增强外，CNCF 版本的 shim 针对普通容器管理做了两个优化：

Exec 管理将由容器所属的 shim 管理
不同容器之间可以共享同一个 shim 进程

不同容器共享同一个 shim 进程的方案是用来优化 kubernetes 场景下的内存资源问题。一个具有 RPC 能力的 shim 活跃内存就有 3 MB (计算逻辑为 memory.usage_in_bytes - memory.stat.inactive_file), 而一个 Pod 默认就有两个容器；而在云原生场景下，业务容器配置个日志采集、Service Mesh 等边车型容器是非常常见的。如果一个容器就需要 3 MB 常驻内存，kubernetes 场景下节点一般都有 10-20+ Pod, 啥都没做就轻松消耗上百兆资源，放大到整个基建以及数据中心都是比较客观的数字。共享模式可优化多容器的 Pod 资源，边车型的容器越多时，效果越明显。

1.4 有可能去除 runC shim 吗?

在 containerD 架构设计里，shim 是一个很关键的抽象概念，它做到了 Out-of-Tree 模式对接各式各样的容器运行时，尤其是对 Kata-Container Host 管控面的优化上发挥了重要作用。但对于我们常用的 runC 运行时而言，它并不需要常驻的 QEMU 进程，也不需要常驻的 Application Kernel，容器进程和普通进程一样，进程间共享同一个内核。那么回顾下最初 dockerd 的管控逻辑，如果我们能保证进程退出码不会丢失，那么 runC shim 是否可以被优化掉？

答案是可以！

我个人开源了 embedshim 项目，它是一个 containerD 第三方容器管控插件，它不仅保证容器退出码不会丢失，还能确保 containerD 重启后依然能感知到容器进程的退出事件。使用它之后，runC shim 将被移除，缩短整个容器管控链路，节省不必要的资源开销。

2. 内核是我们的边车！

embedshim 将监控进程退出码的工作几乎都交给了内核。

首先内核支持使用 sched_process_exit 来追踪处理进程退出的事件。在当前讨论的场景下，我们不仅需要能感知到容器进程退出事件，还需要将容器进程退出码持久化，以防止 containerD 进程重启过程中丢失。在这里，eBPF 是我们的最佳选择。临时文件系统 BPF-FS 可以持久化 关联后 的 eBPF 程序和 Map 存储。即使注入 eBPF 程序的进程退出了，内核依然可以调用这些持久化后 eBPF 程序来响应事件，比如 sched_process_exit 事件。

除此之外，更重要的是 v5.4 内核还提供了 pidfd pollable 能力。pidfd 是和某一个正在运行的进程相关联的文件句柄，这个句柄可用来给关联进程定向发送信号、复制被关联进程的文件句柄以及感知被关联进程的退出事件。感知被关联进程的退出事件 便是我们提到的 pidfd pollable。它打破了 subreaper 必须是父进程的限制，即使是非父进程也可以感知到类 SIGCHLD 信号。这个信号通知发生在 sched_process_exit 事件处理之后，换句话说，pidfd 文件句柄可读则意味着我们可以从 eBPF Map 中读取关联进程的退出码了。

有了 sched_process_exit 事件处理程序以及 pidfd pollable 这两大神器，containerD 将不再需要 subreaper，容器进程可以放心交给一号进程管理。在过去 shim 是我们的边车，而现在内核是我们的边车，而且车将开的更稳！

3. embedshim 进程管理

下图为 embedshim 设计概况，除了借助内核能力外，embedshim 还依赖 OCI runC 容器创建流程设计。

runC 把创建容器分为两阶段: create 和 start。早期我并没有参与过定制 OCI Runtime 标准的讨论，但从个人角度来看，两阶段的设计其实是有利于做进程管理的。首先 runC-create 会 fork 出 runC-init 进程，然后它通过 UDS 和 runC-init 进程进行交互，比如 cgroup 参数写入、数据卷的挂载、capability 权限配置、当然还有一些 Hook 的调用等等。之后 runC-create 进程将退出，而 runC-init 进程通过 exec.fifo 有名管道等待 runC-start 的指令来完成最后的 exec 系统调用（切换成容器进程）。runC-create 和 runC-start 两命令行之间所产生的停端间隔可以让集成方做一些能力拓展，尤其是那些需要在 exec 系统调用前完成的事情。

在 embedshim 这个场景下，我用它来追踪容器进程的状态变化。如果 runC 创建容器不是两阶段，那么遇到 短命 的容器进程，比如 flannel CNI initContainer，我们很可能还没开始注册追踪任务，容器进程就退出了，而两阶段创建可确保不出现这样的问题。所以在 runC-create 成功执行后， embedshim 会给该容器分配一个独一无二的 TraceID 来标识容器进程 PID，它将追踪任务注册到 tracking_tasks eBPF Map 存储里，并使用 pidfd_open 来监控进程退出事件。一旦监控准备工作完毕， containerD 就会开始调用 runC-start 来启动容器进程。只要容器进程一退出，embedshim 注册的 eBPF 追踪程序便会将其退出码持久化到 exited_events eBPF Map 存储里，并去除追踪任务，其中 exited_events 使用 TraceID 做容器退出码的索引。因为 PID 有复用的风险，利用 exited_events 存储可确保退出码信息准确。内核调用追踪程序后，它会通过 pidfd 来通知 embedshim 有容器退出了，而 embedshim 会拿着容器退出码来更新容器状态。

当然除了容器进程外，我们还需要支持容器的运维进程。runC-exec 运维命令并非两阶段创建模型，它直接采用 execve 模型来创建运维进程。这些运维进程一般都比较短命，尤其是 Pod Probe 类型的探针性命令。为了保证能正确捕捉到 exec 进程的退出事件，embedshim 通过 runcext 进程以 subreaper 的身份调用 runC-exec。runcext 进程调用完毕 runC-exec 后，它会通过 UDS 将 exec 进程状态反馈给 embedshim。即使 exec 进程真的短命，runcext 也能通过 waitpid 系统调用感知它的退出码。针对这种场景，embedshim 可直接将状态更新到 exited_events 存储里，无需走 sched_process_exit 事件处理模式。

runcext 一定程度上模拟了两阶段创建，并不原生化。为了解决这个问题，我在 runC 社区提出了 Feature Request: Support Two Phases to Start Exec Process like Init 请求，目前已两个 runC Maintainer 同意了该提案，后续我会把这部分优化提交到社区。

这就是 embedshim 管理容器进程的整体思路。embedshim 监控一个容器进程的退出码仅需要 32B 的内存空间，即使有上千个容器进程也仅需 KB 级别的内存，它不仅去除了 shim subreaper 缩短了调用链路，还减少了不必要的内存开销，这可能就是内核边车的价值所在。

4. 简化容器 stdio 重定向：可支持 99% 场景

shim 边车并非直接将有名管道作为容器进程的标准输入输出，而是中间加了一层转发，如下图所示。

shim 边车将无名管道的一端作为容器的标准输出，另外一端用来将数据同步到有名管道上，由接收方 dockerd 或者 containerD 消费。因为有名管道开启了读写模式，所以即使接收端退出了也不会出现 SIGPIPE 错误，接收端重启后还是可以接管容器输出。同样地，标准输入的处理和标准输出一样，只是数据方向相反。

单纯从容器标准输出来看，shim 边车的确不应该做这一层转化，直接将有名管道交给容器即可。但交互模式下的标准输入是必要的。*nux 系统提供了管道来将多个命令行串联在一起，比如 echo hello | cat，echo 传递 hello 之后并发送 EOF，这样 cat 打印 hello 完毕后会认为已经没有输入，它便自动会退出。这种模式在容器场景下也十分常见。但如果我们直接将 读写模式 的有名管道作为容器进程的标准输入，那么我们将无法给容器进程发送 EOF，它将永远等待用户的输入，所以 shim 边车只能利用无名管道的模式来做 EOF 信号通知。可能是为了方便管理吧，shim 边车也将这种中转模式应用到了标准输出。

embedshim 同样也采用中转的方式来处理标准输入，但它直接将读写模式的有名管道交给了容器的标准输出，减少标准输出的拷贝。embedshim 插件属于 containerD 进程的一部分，一旦 containerD 重启，那么容器进程的 输入端 将收到 SIGPIPE 错误。对于这种情况，个人觉得是可以接受的。在交互模式下，用户会感知到容器引擎的停服。而线上环境的大部分场景都是采用 Headless 无交互模式，容器进程的输入端都是 /dev/null，而标准输出的状态由有名管道做持久化，不会因为 containerD 停服而出现 容器输出端 的 SIGPIPE 错误。

所以从个人使用经验来看，只要不强求恢复停服前的交互输入，embedshim 基本上能满足大部分人的需求，至少 Kubernetes 场景下的容器都可以满足。

5. v0.1.0 版本发布

最后，我刚发布了 embedshim v0.1.0 版本，它目前经过 CRI-TEST 测试套件的验证，也欢迎大家使用来提提意见。

Towards truly portable eBPF

Thu, 10 Mar 2022 00:00:45 +0800

在上一篇 eBPF Loader 中介绍了 eBPF 加载器的工作原理。Compile-Once Run-Everywhere (CO-RE) 是目前社区的发力方向，但它要求内核版本支持 CONFIG_DEBUG_INFO_BTF=y 特性。除了 REHL 等商业公司会回合高版本特性到当前支持的商业版本之外，大部分社区免费版本都要求 >= 5.5 版本的内核。为了能在当前主流的 4.14, 4.15, 4.18, 4.19 内核版本上支持 eBPF CO-RE 特性， Aqua Security 的工程师在 2021 Linux Plumbers Conference - Towards truly portable eBPF 议题上展示了它们的想法: BTF-Hub + Embedded BTF。

1. BPF Portable

作为用户提供的程序片段，eBPF bytecode 可直接注入到 linux 内核里直接读取和操作内核运行态的内存数据，它的可观测性和对内核模块的可拓展性受到系统开发者的青睐。这是它强大的优势，但同时也是一大痛点：只有获得了目标内核版本的头文件才能保证 eBPF 程序能正确地访问内存数据。

早期在使用 bcc 诊断工具时，我们需要 llvm/clang 做 eBPF 实时编译；如果开发 - 测试 - 线上环境没有做到版本的强一致，那么即使逃过了 BPF Verifier 的审判，程序也会因为没有正确地读取内存 (偏移地址不正确) 而出现非预期的行为。

虽然 eBPF 程序的非预期行为不会导致内核崩溃，但研发体验和内核模块开发差别不大：eBPF 开发者还是需要针对不同的内核版本编译出不同的版本，线上内核版本越多，测试上线的成本就越高。下图为 Falco 为不同版本提供的内核模块；如果 eBPF 没有移植能力的话，它的发布模式其实和普通的内核模块差别不大。一次构建，到处运行 的能力直到 BPF Type Format (BTF) 的出现才有了质的飞跃。

1.1 BTF

BTF 描述了程序所需要的数据结构信息，包括结构体大小名字，字段类型和偏移量等等。它一般通过 pahole 将 DWARF 调试信息转化得到，其压缩比非常高，一个常用内核的 BTF 仅需要 1-5 MB。正是因为它压缩比高、易携带，社区通过 CONFIG_DEBUG_INFO_BTF=y 编译选项来决定将其注入到 vmlinux 上，携带该信息的内核将通过 /sys/kernel/btf/vmlinux 路径作为外部获取的接口。

BTF 同 DWARF 一样，我们可以根据 BTF 信息来生成了头文件。对于开发者而言，BTF 改善体验的第一件事就是仅需要一个头文件就可以拿到内核所使用的所有结构体描述。

$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

但仅靠 BTF 还是无法保证 eBPF 程序能在目标内核上正确地获取内存地址，只能通过修正、校对现有指令才行。

1.2 preserve_access_index

以 Tracing 为例，eBPF 程序会经常使用进程元数据 task_struct，内核提供了 bpf_get_current_task 接口来获取当前上下文的进程信息，这个接口的返回值将直接指向内核运行态地址。从安全角度考虑，eBPF 访问内核空间的地址必须要走 bpf_probe_read_kernel 调用来完成。比如，我们想获取当前上下文的父进程 pid, 那么我们是无法直接通过 task->real_parent->pid 来读取；当前 libbpf 库为我们提供了 BPF_PROBE_READ 宏来读取父进程的 pid。

BPF_PROBE_READ 宏展开后的编译结果显示两次 task->real_parent, real_parent->pid 读取，每次都是基于 vmlinux_508.h 头文件 (内核 v5.8) 的偏移量来读取。这和我本地的目标内核 (v5.13) 偏移量存在差异；即使程序不报错，它也不是按照预期来进行。为了解决这个问题，社区在编译器上做了优化。

libbpf 提供了新的宏 BPF_CORE_READ，它使用 __builtin_preserve_access_index 包住被读取的内核空间地址，比如 task->real_parent, real_parent->pid，那么在编译阶段会将访问路径 0:57，0:54 作为 relocation 的符号保存在 .BTF.ext section 里，其中 57 和 54 分别是 real_parent 和 pid 在 v5.8 内核 task_struct 结构体里的第 57 和 54 个字段。加载器会根据访问路径来比较源和当前内核对应数据结构的差异。当找到匹配对象后，那么将会以当前内核的偏移地址来修改原先的指令，保证程序可以正确运行；否则将会加载失败。

早期 preserve_access_index 是配合 BPF_CORE_READ 来使用，现在直接将这个拓展放到每一个内核结构上，保证编译期间能注入 relocation 信息。当然这里仅仅列列出了 field offset relocation，还有 ENUM, BITFIELD 等模式，这些模式仅在结构匹配算法上存在差异，整体还都是先匹配再修改指令，在此就不再赘述。

$ cat vmlinux.h
#ifndef __VMLINUX_H__
#define __VMLINUX_H__

#ifndef BPF_NO_PRESERVE_ACCESS_INDEX
#pragma clang attribute push (__attribute__((preserve_access_index)), apply_to = record)
#endif
...

eBPF 加载器在做指令修改时，它需要当前内核的 BTF 信息。一般来说，这个特性仅在 >= v5.5 内核才支持，还有很多用户在使用 4.x 的内核。因可观测性的需求强行升级内核并不现实，我们需要寻求其他方式来获得 BTF 信息。

2. BTF-Hub and embedded BTF

内核在编译时，它是通过 pahole 将 DWARD 信息转化成 BTF，并在 link-vmlinux 阶段将数据放到 BTF section 中。所以，即使是低内核版本，只要能拿到对应内核的编译调试信息，我们就可以独立转化并得到 BTF 信息，它和 /sys/kernel/btf/vmlinux 读出来的结果一致。eBPF 加载器是在用户态做指令改写，只要 eBPF 加载器能识别到指定的 BTF 信息即可。

Towards truly portable eBPF 议题提出了 BTF-Hub：Aqua Security 工程师将 ubuntu/centos/federo/debian 对外开放的 DWARF 信息转化成对应的 BTF 信息，并配合加载器使用就可以完成 CO-RE 能力了。

这个方案解决了低内核版本不支持导出 BTF 的问题。虽然每一个内核版本 BTF 信息不大，但也抗不住小版本的迭代，就目前 BTF-Hub 提供 ubuntu 发行版的可用 BTF 信息就有 200 MB。在演讲者看来它和 falco 驱动的多内核版本构建差别不大，会场主持人也开玩笑说：“如果 github 挂了，我们就获取不到 BTF 数据了”。演讲者提出了比较有意思的想法: Embedded BTF。

Embeded BTF 核心设计就是去除无用的 BTF 信息。举个例子， bcc 提供了 libbpf-tools 38 个 eBPF 程序，但这些程序使用的内核数据结构只是内核 BTF 信息的子集，只要能获取出这个子集就能降低携带 BTF 信息成本，这个提取的方案叫做 BTFGen，已经被 Linux bpf-next 所接受了。下面可以看下我本地使用的效果：

4.9MB 里只有 3.3KB 数据有用，对于一类 eBPF 程序而言，即使把尽可能多内核版本的 BTF 随身携带也不会带来存储空间压力；当线上内核版本较为统一时，开发者甚至还可以将 BTF 信息放入到容器镜像或者应用程序的二进制里。

对我而言，这个方案的确是让低版本的内核享受到 CO-RE 的好处，甚至会改变 bcc 工具包的发布方式。

3. Summary

除了 BTF-Hub 和 Embedded BTF 之外，演讲者还介绍了很多他们遇到的 CO-RE 挑战，实战编程中还是有一定的参考意义，值得一看。

eBPF Loader

Sun, 27 Feb 2022 23:00:53 +0800

0. What is eBPF?

Extended Berkeley Packet Filter (eBPF) 是由 Linux 提供的内核技术，它是以安全沙盒 (Virtual Machine) 的形式运行用户定义的 ByteCode 来观测内核运行状态以及拓展内核的能力，开发者无需定制内核模块就可以高效地完成对现有模块的拓展。eBPF 安全沙盒是嵌入到 Linux 内核运行态的关键路径上，通过事件订阅的形式来触发 eBPF 程序，其运用场景有：

cilium 在 L3/L4 提供高效的网络转发能力
bcc 提供常用的观测组件来定位业务遇到的性能问题
Google 内核调度拓展 ghOSt

我过去主要使用 eBPF 在观测和排查一些节点的性能问题。由于底层基础设施能力以及业务运行模型存在差异，这将导致节点组件出现不在预期内的行为，而在本地又难以复现，大大增加了沟通和排查成本。而 eBPF 可以捕捉到程序在内核里的状态，甚至是短命的程序调用 (比如容器领域的 runC 命令) 都可以捕捉, 它可以最大程度地呈现程序的运行状态来提升问题的排查效率。

比如前段时间遇到的 containerD CRI 组件创建容器超时的问题，我通过 bcc stackcount 捕抓到根因: umount 可写的文件系统时会调用底层文件系统的刷盘动作，它用来保证数据能及时落盘；但这同时也给磁盘带来压力，IOPS 弱的数据盘将会拖慢 umount 调用。对于一个不熟悉内核代码的开发者来说，eBPF 观测类工具暴露出的关键函数路径就和日志的错误信息一样，全局搜索相应的内核代码段，然后顺藤摸瓜，总会找到些蛛丝马迹。

eBPF 目前发展的比较快，其中一个重要的支线是 Compile-Once Run-Everwhere (CO-RE) ，这有点像 docker 镜像分发的 Build-Once Run-Anywhere, 下面将主要围绕兼容性去介绍如何加载 eBPF 程序。

1. Type Metadata

eBPF 允许读取和修改内核运行态的数据，常见数据结构有线程的 task_struct 和网络子系统的 __sk_buff。这些常用的结构体在不同内核版本之间存在差异，比如某一个字段位于 task_struct 结构体的第 16 字节处，然而升级到某一个内核版本后，这个字段被移到第 24 字节处，那么原先编译好的 eBPF 将无法正常工作。早期的 bcc 组件在使用过程中都是在目标节点上利用现有的内核相关头文件来编译。但即使如此，bcc 也没法解决字段名被更换的问题，字段名变化容易出现编译不通过。因此早期大部分情况下，开发者还是会选择根据不同内核版本出不同的二进制，这给测试验证带来了极大的成本。

为了解决类型匹配问题，eBPF 需要额外的类型系统的描述数据。eBPF 程序所使用的数据类型和函数接口都通过常用的调试信息 DWARF 描述, 如下图所示 bootstrap.bpf.c 编译完毕后的 task_struct 部分类型信息，其中 thread_info 和 state 是 task_struct的字段。

// use llvm-dwarfdump
...

0x00005f27:   DW_TAG_structure_type
                DW_AT_name      ("task_struct")
                DW_AT_byte_size (0x1ac0)
                DW_AT_decl_file ("xxx")
                DW_AT_decl_line (883)

0x00005f2f:     DW_TAG_member
                  DW_AT_name    ("thread_info")
                  DW_AT_type    (0x00006775 "thread_info")
                  DW_AT_decl_file       ("xxx")
                  DW_AT_decl_line       (884)
                  DW_AT_data_member_location    (0x00)

0x00005f3a:     DW_TAG_member
                  DW_AT_name    ("state")
                  DW_AT_type    (0x00006793 "volatile long")
                  DW_AT_decl_file       ("xxx")
                  DW_AT_decl_line       (885)
                  DW_AT_data_member_location    (0x10)

...

DWARF 对类型描述十分详细，包含类型字段的大小、字段的偏移量等等。当 eBPF 加载时，只需要在当前 Linux 内核的 DWARF 调试信息找到最匹配 eBPF 程序中的类型即可，即使字段的偏移量发生改变也没关系，只需 Relocation 成对应的偏移量即可。但 DWARF 调试信息为纯文本格式，内核的调试信息大概有 100+ MB，让内核启动带上这些信息成本太高了，这里需要可压缩的类型格式。

内核社区提出了 BPF Type Format (BTF), 它可以将 100+ MB DWARF 信息压缩到 1.5 MB，eBPF 以及 Linux 内核都方便携带，具体的压缩算法可以阅读 BTF deduplication and Linux kernel BTF, 在此就仅仅展示 BTF dump 信息。

// use pahole -JV
...

[624] STRUCT task_struct size=6848
        thread_info type_id=625 bits_offset=0
        state type_id=626 bits_offset=128
        stack type_id=29 bits_offset=192
        usage type_id=308 bits_offset=256
        flags type_id=37 bits_offset=288
        ptrace type_id=37 bits_offset=320
        on_cpu type_id=10 bits_offset=352
        wake_entry type_id=628 bits_offset=384
        cpu type_id=37 bits_offset=512
...

当每个字段的偏移量以及类型信息可通过极低的成本携带时，eBPF 加载器可以使用类型匹配策略来将使用体验提升到新的高度。下面将介绍加载器的核心工作 - 重定向。

2. Relocation

eBPF 一般来说是由 clang/llvm 编译 C 文件得到的 ELF 二进制文件，其中它采用十个通用的寄存器、只读的 Frame Pointer 寄存器以及使用长度为 64 bits 的指令集。加载器需要解决重定向后才能进行 BPF Verifier，而重定向内容主要涉及到三部分 Map，CO-RE 以及函数调用。

2.1 Map

eBPF 程序和程序之间以及同用户态之间的交互都是通过 Map 来实现，而 Map 增删改查是通过文件句柄的形式来操作，而这依赖 BPF_MAP_CREATE bpf 系统调用。

// https://man7.org/linux/man-pages/man2/bpf.2.html

bpf(BPF_MAP_CREATE, &bpf_attr, sizeof(bpf_attr));

union bpf_attr {
  struct { /* anonymous struct used by BPF_MAP_CREATE command */
      __u32   map_type;       /* one of enum bpf_map_type */
      __u32   key_size;       /* size of key in bytes */
      __u32   value_size;     /* size of value in bytes */
      __u32   max_entries;    /* max number of entries in a map */
      __u32   map_flags;      /* prealloc or not */
  };
}

bpf_attr 定义可以从 ELF 二进制的 section .maps 或者 maps 中获取，如下面的代码片段所示。bpf_map_def 定义数据模式已经被弃用了，如下图所示，加载器需要严格按照固定的偏移量来读取 bpf_attr，相比 BTF 类型系统而言，编码和使用体验都差很多。

// Use BTF
struct {
	__uint(type, BPF_MAP_TYPE_HASH);
	__uint(max_entries, 8192);
	__type(key, pid_t);
	__type(value, u64);
} exec_start_btf SEC(".maps");

// Use symbol but it has been deprecated
struct bpf_map_def SEC("maps") exec_start_symbol = {
	.type        = BPF_MAP_TYPE_HASH,
	.key_size    = sizeof(pid_t),
	.value_size  = sizeof(u64),
	.max_entries = 8192,
};

// https://github.com/fuweid/demos/tree/master/ebpf
➜  llvm-readelf -s -x maps ./.output/example-map-relo.bpf.o 

Symbol table '.symtab' contains 6 entries:
   Num:    Value          Size Type    Bind   Vis       Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT   UND 
     1: 0000000000000000     0 SECTION LOCAL  DEFAULT     2 tp/sched/sched_process_exec
     2: 0000000000000000   184 FUNC    GLOBAL DEFAULT     2 handle_exec
     3: 0000000000000000    32 OBJECT  GLOBAL DEFAULT     5 exec_start_btf
     4: 0000000000000000    20 OBJECT  GLOBAL DEFAULT     4 exec_start_symbol
     5: 0000000000000000    13 OBJECT  GLOBAL DEFAULT     3 LICENSE
Hex dump of section 'maps':
          .type=1     .key_size=4   .value_size=8   .max_entries = 8192
0x00000000 01000000   04000000      08000000        00200000 ............. ..
          .flags=0
0x00000010 00000000

当加载器读取 eBPF ELF 时，代码段 section, 比如 tp/sched/sched_process_exec, 其对应的重定向符号的偏移量会在 .reltp/sched/sched_process_exec 描述，如下面的结果所示，其中 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 DWORD 指令将是我们要替换的指令。

➜  llvm-objdump -dr ./.output/example-map-relo-btf.bpf.o

./.output/example-map-relo-btf.bpf.o:	file format elf64-bpf


Disassembly of section tp/sched/sched_process_exec:

0000000000000000 <handle_exec>:
       0:	85 00 00 00 0e 00 00 00	call 14
       1:	77 00 00 00 20 00 00 00	r0 >>= 32
       2:	63 0a fc ff 00 00 00 00	*(u32 *)(r10 - 4) = r0
       3:	85 00 00 00 05 00 00 00	call 5
       4:	7b 0a f0 ff 00 00 00 00	*(u64 *)(r10 - 16) = r0
       5:	bf a2 00 00 00 00 00 00	r2 = r10
       6:	07 02 00 00 fc ff ff ff	r2 += -4
       7:	bf a3 00 00 00 00 00 00	r3 = r10
       8:	07 03 00 00 f0 ff ff ff	r3 += -16
       9:	18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00	r1 = 0 ll
		0000000000000048:  R_BPF_64_64	exec_start_btf
      11:	b7 04 00 00 00 00 00 00	r4 = 0
      12:	85 00 00 00 02 00 00 00	call 2
      13:	95 00 00 00 00 00 00 00	exit

➜  llvm-readelf -r ./.output/example-map-relo-btf.bpf.o

Relocation section '.reltp/sched/sched_process_exec' at offset 0x6d8 contains 1 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name
0000000000000048  0000000300000001 R_BPF_64_64            0000000000000000 exec_start_btf

当前阅读最新的内核文档 (v5.17.0-rc5) 没有说明如何替换 eBPF Map 符号指令，反倒是 libbpf 加载器中有说明：当指令类型为 LD_IMM64 且原寄存器编号不为 0 时，那么该指令可以被重写成 MAP 相关的操作，重写规则如下面的代码所示。回顾上头要被替换指令，其开头 18 为 LD_IMM64 且 01 是 r1 寄存器，替换的 Map 符号符合该模式；因此通过 BPF 系统调用申请 Map 文件句柄之后，加载器可以把代码段中第 52 个 Byte 替换成对应的文件句柄即可。

需要说明的是，替换的并不是 .reltp/sched/sched_process_exec 中提到的第 48 Byte。BPF 并不采用 Elf64_Rela 来携带 Addend，而是针对不同的重定向类型作了特殊的约定，比如 R_BPF_64_64 类型的替换地址为 重定向声明的偏移量 + 4 = 48 + 4 = 52。

// https://github.com/libbpf/libbpf/blob/v0.7.0/include/uapi/linux/bpf.h#L1121

/* When BPF ldimm64's insn[0].src_reg != 0 then this can have
 * the following extensions:
 *
 * insn[0].src_reg:  BPF_PSEUDO_MAP_[FD|IDX]
 * insn[0].imm:      map fd or fd_idx
 * insn[1].imm:      0
 * insn[0].off:      0
 * insn[1].off:      0
 * ldimm64 rewrite:  address of map
 * verifier type:    CONST_PTR_TO_MAP
 */
#define BPF_PSEUDO_MAP_FD	1
#define BPF_PSEUDO_MAP_IDX	5

为了方便用户态修改程序中的只读常量，clang/llvm 会将 const volatile 声明的全局变量合并成一个结构体，并将为其声明成只有 [一个元素的 Map]，数据按照顺序存储在第一个 Value 里。因为不同变量在结构体的偏移量不同，那么指令改写逻辑有点差异，如下面的代码所示。

// https://github.com/libbpf/libbpf/blob/v0.7.0/include/uapi/linux/bpf.h#L1135

/* insn[0].src_reg:  BPF_PSEUDO_MAP_[IDX_]VALUE
 * insn[0].imm:      map fd or fd_idx
 * insn[1].imm:      offset into value
 * insn[0].off:      0
 * insn[1].off:      0
 * ldimm64 rewrite:  address of map[0]+offset
 * verifier type:    PTR_TO_MAP_VALUE
 */
#define BPF_PSEUDO_MAP_VALUE		2
#define BPF_PSEUDO_MAP_IDX_VALUE	6

不过使用的时候一定要注意用户态的类似是不是和 eBPF 程序中的一致，感兴趣的可以查看 iovisor/bcc#3777。

2.2 Field Offset Rewrite

前面提到了 Linux 内核社区设计可压缩的 BTF 格式，我们通过工具转化 DWARF 数据成 BTF，那么内核里所有的数据结构都可以通过 BTF 反推成 C 头文件。当我们有了这个 All-in-One 头文件，那我们就不再需要在安装 kernel-headers 了！没人喜欢安装一堆依赖，不是吗？！

➜  bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

我们来看一个具体的例子吧， example-field-offset-rewrite 读取当前 exec 进程 task_struct 结构体，并返回它的 real_parent 的 pid。如下图所示，我们可以看到没有加载前的访问指令是符合 vmlinux.c 描述的偏移量的：

real_parent 在 task 变量的 9472 bits = 1184 bytes 的位置；
同时 real_parent 本身也是一个 task_struct 类型的变量，它的 pid 字段将在 9344 bits = 1168 bytes 位置读取。

➜  llvm-objdump -dr ./.output/example-field-offset-rewrite.bpf.o

./.output/example-field-offset-rewrite.bpf.o:	file format elf64-bpf


Disassembly of section tp/sched/sched_process_exec:

0000000000000000 <handle_exec>:
       0:	85 00 00 00 23 00 00 00	call 35
       // 使用 Ubuntu v5.8 内核 BTF dump 出来的 vmlinux.c 
       // [596] STRUCT task_struct size=6848
       //   ...
       //   real_parent type_id=594 bitfield_size=0 bits_offset=9472
       1:	b7 01 00 00 a0 04 00 00	r1 = 1184  <== 1184 Bytes
       2:	0f 10 00 00 00 00 00 00	r0 += r1
       3:	bf a1 00 00 00 00 00 00	r1 = r10
       4:	07 01 00 00 f0 ff ff ff	r1 += -16
       5:	b7 02 00 00 08 00 00 00	r2 = 8
       6:	bf 03 00 00 00 00 00 00	r3 = r0

      // bpf_probe_read 调用读出 real_parent task_struct == task->real_parent
       7:	85 00 00 00 71 00 00 00	call 113

      // [596] STRUCT task_struct size=6848
      //   ...
      // pid type_id=1800 bitfield_size=0 bits_offset=9344
       8:	b7 01 00 00 90 04 00 00	r1 = 1168
       9:	79 a3 f0 ff 00 00 00 00	r3 = *(u64 *)(r10 - 16)
      10:	0f 13 00 00 00 00 00 00	r3 += r1
      11:	bf a1 00 00 00 00 00 00	r1 = r10
      12:	07 01 00 00 fc ff ff ff	r1 += -4
      13:	b7 02 00 00 04 00 00 00	r2 = 4
      14:	85 00 00 00 71 00 00 00	call 113
      15:	61 a0 fc ff 00 00 00 00	r0 = *(u32 *)(r10 - 4)
      16:	95 00 00 00 00 00 00 00	exit

但上面的 eBPF 指令访问 task_struct 内部字段是基于 v5.8 内核 BTF 构建的，和我当前的 v5.13.0 内核版本存在较大的差异， real_parent 和 pid 偏移量都变化较多。而且 llvm-objdump -dr 并没有显示哪些 [读取字段的指令] 需要替换。由于这部分指令修改策略还没有更新到当前最新的 v5.17.0-rc5 版本上，只能通过阅读代码来获取。

➜  uname -a
Linux chaofan 5.13.0-30-generic #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

➜  bpftool btf dump file /sys/kernel/btf/vmlinux | less
...
[174] STRUCT 'task_struct' size=9472 vlen=232
...
  'real_parent' type_id=175 bits_offset=18816
  'pid' type_id=60 bits_offset=18688

通过查看代码，我发现主要由三个 Patch 来提供替换的编码信息：

其中 llvm 的 Patch 做到了在 BTF 中保留对内核数据结构的访问路径, 如下面的代码片段所示，目前 libbpf 加载器一次的访问路径的最大深度为 9。

// https://github.com/cilium/ebpf/blob/v0.8.1/internal/btf/core.go#L435
struct sample {
  int a;
  struct {
    int b[10];
  }
};

struct sample s = ...;                                                                                         
int x = &s->a;     // encoded as "0:0" (a is field #0)
int y = &s->b[5];  // encoded as "0:1:0:5" (anon struct is field #1,
                   // b is field #0 inside anon struct, accessing elem #5)
int z = &s[10]->b; // encoded as "10:1" (ptr is used as an array)

// More info： https://llvm.org/docs/LangRef.html#getelementptr-instruction

而 0:1:0:5 这样的信息作为字符串保存在 .BTF section 中，而重写指令的偏移量则保存在 .BTF.ext 的 sub-section 中，具体的数据结构如下：

// https://www.kernel.org/doc/html/latest/bpf/btf.html
struct btf_ext_info_sec {
   __u32   sec_name_off; /* offset to section name */
   __u32   num_info;
   /* Followed by num_info * record_size number of bytes */
   __u8    data[0];
};

// https://github.com/libbpf/libbpf/blob/v0.7.0/include/uapi/linux/bpf.h#L6560
struct bpf_core_relo {
  __u32 insn_off;              // 一开始是 section 偏移量，读出来一般都会修改成 [基于所在函数的偏移量]，
                               // 方便后续不同 section 函数指令合并后的指令重写。

  __u32 type_id;               // 以上面 struct sample，那么 type_id 为 struct sample 的 BTF ID                                            
  __u32 access_str_off;        // 0:1:0:5 
  enum bpf_core_relo_kind kind;
};

// sub-section layout about bpf_core_relo
btf_ext_info_sec for section #1 /* bpf_core_relo for section #1 */
btf_ext_info_sec for section #2 /* bpf_core_relo for section #2 */
...

有了这样访问路径信息后，加载器会读出本地 BTF 信息按照访问路径进行相应的结构体匹配，当然这里是 [尽力去找最匹配的结果]，比如结构体的名字要一致，相应的结构体大小要一致等等。如果存在匹配结果，那么 bpf_core_relo.insn_off 对应的指令将会被修改；否则，加载将会返回失败。

[一次编译，到处运行] 将 eBPF 使用体验都提升了好几个档次，想想看，OCI Artifacts 是不是可以 eBPF 程序作分发标准化呢？!

2.3 CALL INSN on pc-relative?

eBPF 是将每一个函数挂到相应的事件触发器上。一般来说，调用自定义的函数都会被 inlined 掉，即使代码段不在同一个 section 里。如下面的代码所示，这样程序是不需要重写指令的。

# https://github.com/fuweid/demos/blob/master/ebpf/example-func-inline.bpf.c
➜  llvm-objdump -dr ./.output/example-func-inline.bpf.o

./.output/example-func-inline.bpf.o:	file format elf64-bpf


Disassembly of section .text:

0000000000000000 <double_ts_in_text>:
       0:	bf 10 00 00 00 00 00 00	r0 = r1
       1:	67 00 00 00 01 00 00 00	r0 <<= 1
       2:	95 00 00 00 00 00 00 00	exit

Disassembly of section tp/sched/sched_process_exec:

# 全部 inlined 到 handle_exec， 无需跳转
0000000000000000 <handle_exec>:
       0:	85 00 00 00 05 00 00 00	call 5
       1:	67 00 00 00 01 00 00 00	r0 <<= 1
       2:	95 00 00 00 00 00 00 00	exit

如果 double_ts 函数不 inlined，那么编译后的结果如下。可以看到函数代码段在不同的 Section 中，加载器需要把所有相关的代码片段都 [追加] 到 handle_exec 的末尾，然后根据重定向的偏移量来修改指令。

需要注意的是，内核文档在描述 eBPF CALL 指令时并没有说 Immediate 是不是相对值。我是通过查看 libbpf 加载器中 BPF_PSEUDO_CALL 描述才知道这是一个相对值，偏移量的计算也是约定值。函数调用重写相比 MAP/Field Offset 重写要简单些，一般这部分的指令修改都是放到最后做。

# https://github.com/fuweid/demos/blob/master/ebpf/example-func-noinline.bpf.c

➜  llvm-objdump -dr ./.output/example-func-noinline.bpf.o

./.output/example-func-noinline.bpf.o:	file format elf64-bpf


Disassembly of section .text:

0000000000000000 <double_ts>:
       0:	bf 10 00 00 00 00 00 00	r0 = r1
       1:	67 00 00 00 01 00 00 00	r0 <<= 1
       2:	95 00 00 00 00 00 00 00	exit

Disassembly of section tp/sched/sched_process_exec:

0000000000000000 <handle_exec>:
       0:	85 00 00 00 05 00 00 00	call 5
       1:	bf 01 00 00 00 00 00 00	r1 = r0
       2:	85 10 00 00 ff ff ff ff	call -1
		0000000000000010:  R_BPF_64_32	.text
       3:	95 00 00 00 00 00 00 00	exit

# 修改后的结果 dump from kernel
int handle_exec(struct trace_event_raw_sched_process_exec * ctx):
; ts = bpf_ktime_get_ns();
   0: (85) call bpf_ktime_get_ns#135136
; ts = double_ts(ts);
   1: (bf) r1 = r0
   2: (85) call pc+1#bpf_prog_6aadb6445c8badae_F
; return ts;
   3: (95) exit
u64 double_ts(u64 ts):
; u64 double_ts(u64 ts) {
   4: (bf) r0 = r1
; return ts + ts;
   5: (67) r0 <<= 1
; return ts + ts;
   6: (95) exit

3.0 Conclusion

本文只是简单介绍了 eBPF 加载器是怎么修改指令的，虽然还有很多细节没有提到，比如 CALL bpf_ktime_get_ns 指令是如何工作，以及 eBPF 尾调用如何拼接在一起等等，但大体的工作方式差不多，建议读一读 libbpf 加载器，或者 cilium/ebpf go 代码，还是比较有意思的。

go sync.Mutex 源码阅读

Sun, 21 Jun 2020 18:00:53 +0800

Linux Kernel 提供 Semaphore/Mutex 来实现线程间的同步机制，可保证在同一个时间段只有少量的线程可以访问同一块资源（也称为进入临界区域）。线程之间要通过竞争来获得访问权限，一旦竞争失败，线程会进入到阻塞状态；而阻塞的线程只能等待离开临界区域被内核唤醒。

go runtime 提供的 sync.Mutex 并不是采用内核级别的同步机制。作为执行单元的线程一旦阻塞，意味该线程将不再受到 go runtime 控制， go runtime 需要创建新的线程来执行其他 runnable goroutine ，线程的数目会和竞争资源的请求成正比，容易造成资源浪费。而 go 优势是 goroutine 轻量级调度，因此 sync.Mutex 选择在用户态来实现同步机制。

和线程阻塞类似，在无法进入临界区的情况下，goroutine 会主动释放当前的执行单元 - 线程，进入到阻塞状态；在 sync.Mutex 持有者离开临界区之前，阻塞状态的 goroutine 将不会出现在调度队列里。这样被释放的线程会去执行其他 runnable goroutine，提升线程的利用率。

sync.Mutex 结构设计分析

Mutex 也被称之为锁。

// sync/mutex.go

// A Mutex is a mutual exclusion lock.
// The zero value for a Mutex is an unlocked mutex.
//
// A Mutex must not be copied after first use.
type Mutex struct {
        state int32
        sema  uint32
}

每一个 Mutex 实例都有虚拟全局唯一的地址，go runtime 通过 Mutex.sema 地址来维护阻塞的 goroutine 队列。当 goroutine 无法获得锁的情况下，goroutine 主动调用 runtime_Semacquire ，将自己加入锁对应的阻塞队列中；而锁的持有者在释放锁之后，根据当前阻塞情况来调用 runtime_Semrelease 方法，唤醒阻塞队列头部的 goroutine 。

// runtime/sema.go

//go:linkname sync_runtime_Semrelease sync.runtime_Semrelease
func sync_runtime_Semrelease(addr *uint32, handoff bool, skipframes int) {
        semrelease1(addr, handoff, skipframes)
}

//go:linkname sync_runtime_SemacquireMutex sync.runtime_SemacquireMutex
func sync_runtime_SemacquireMutex(addr *uint32, lifo bool, skipframes int) {
        semacquire1(addr, lifo, semaBlockProfile|semaMutexProfile, skipframes)
}

而 Mutex 更多的细节是在 state 字段上。Mutex.state 将 32 bit 划分成四块区域。

高位 3-31 bits 表示当前进入阻塞状态的 goroutine 数目，它直接反应出调用 runtime_SemacquireMutex 的次数。runtime_SemacquireMutex 采用单链表管理队列。正常情况下，阻塞的 goroutine 是通过尾插法的方式加入队列；释放锁的时候会唤醒队列头部的 goroutine，即先入先出，保证了公平特性。

被唤醒的 goroutine 会和新来的 goroutine 竞争加锁，被唤醒的 goroutine 可能会因拿不到锁而重新回到阻塞队列。在处理并发请求时，最先发起的请求会因为竞争关系可能一直拿不到锁，导致个别请求耗时非常长；并发请求越多，这样的问题就越严重。

为了保证公平性，Mutex 引入了 Starving 模式。经历了长时间阻塞，如果被唤醒的 goroutine 还是拿不到锁，它就主动加上 Starving 标志位，该标志位用来告诉新来的 goroutine 要照顾下「阻塞了长时间-刚被唤醒-还拿不到锁的同志」: 不要加锁啦，直接把自己加入到阻塞队列里吧。这样新到达的 goroutine 会被加入到阻塞队列的尾部，之前就在阻塞队列里的 goroutine 就可以优先被唤醒了，降低长尾带来的问题。

那些被唤醒的 goroutine 再次回到阻塞队列时，它们不再重新排队，通过设置 Last In, First Out(LIFO) 来强行插队，保证它是下一个被唤醒的 goroutine。

除了保护公平性之外，Starving 模式还减少了 goroutine 之间的竞争关系。因为运气不好的情况下，新来的 goroutine 会一直拿到锁，导致唤醒的动作白费了，系统线程还不如执行其他 runnable goroutine。

Woken 比特位是用来告知持有锁的调用者：现在有一个活跃状态 goroutine 在尝试拿锁，如果不是处于 Starving 状态，请不要在释放锁的时候做唤醒，尽量让这个活跃的 goroutine 去竞争拿锁，减少不必要的唤醒竞争。

以上是 sync.Mutex 设计介绍，下面我们通过查看代码注释来了解细节。

Unlock 逻辑


// sync/mutex.go

// Unlock unlocks m.
func (m *Mutex) Unlock() {
        if race.Enabled {
                _ = m.state
                race.Release(unsafe.Pointer(m))
        }

        // Fast path: drop lock bit.
        // 通过减一来完成解锁。如果 m.state 没有其他标记位，那么解锁结束。
        // 否则将进入到 slow path，判断是否要唤醒其他阻塞的 goroutine。
        new := atomic.AddInt32(&m.state, -mutexLocked)
        if new != 0 {
                m.unlockSlow(new)
        }
}

func (m *Mutex) unlockSlow(new int32) {
        // 为了防止出现 Unlock 非锁定状态的 Mutex，需要检查下 mutexLocked 标记位。
        if (new+mutexLocked)&mutexLocked == 0 {
                throw("sync: unlock of unlocked mutex")
        }
        // 正常模式，还未出现 Starving
        if new&mutexStarving == 0 {
                old := new
                for {
			// 这里有两大类场景，出现了直接结束掉 slow path:
			//
			// 没有阻塞状态的 goroutine (old >> mutexWaiterShift == 0)
			//
			// 还存在阻塞状态的 goroutine(s)
			//
			// 1. 当前有活跃状态的 goroutine (old&mutexWoken != 0)
			//    选择让当前活跃状态的 goroutine 去竞争锁，减少不必要的唤醒
			//
			// 2. 当前锁已经被其他 goroutine 获取了 (old&mutexLocked != 0)
			//    需要等待释放锁的时候再做唤醒，应直接退出，
			//    交给下一次 Unlock 调用在处理。
			//
			// 3. 当前是一个 Starving 状态 (old&(mutexStarving) != 0)
			//    进入循环前是「非 Starving」状态，而现在确是 Starving 模式。
			//    说明这段时间里出现了 (Lock/Unlock)../Lock 连续调用，
			//    导致「被其他 Unlock 调用唤醒的 goroutine」 拿不到锁，
			//    进入到 Starving 模式。
			//    这种情况下应该直接退出，交给下一次 Unlock 调用在处理了。
                        if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {
                                return
                        }

			// 这个时候 mutexLocked|Starving|Woken 标记位为空，尝试将阻塞数目减一。
			//
			// 只要 CAS 原子操作成功，就可以唤醒阻塞队列头部的 goroutine。
                        new = (old - 1<<mutexWaiterShift) | mutexWoken
                        if atomic.CompareAndSwapInt32(&m.state, old, new) {
                                runtime_Semrelease(&m.sema, false, 1)
                                return
                        }
                        old = m.state
                }
        } else {
		// 因为出现 Starving 状态，说明阻塞时间足够长了，Unlock 调用者会将
		// runtime_Semrelease 函数第二个参数设置成 true，表示会主动释放
		// 当前执行线程，而当前执行线程会直接执行阻塞队列头部的 goroutine。

		// 被唤醒的 goroutine 相当于获得锁的状态了，因为在 Starving 状态下，
		// 新到达的 goroutine 不会竞争锁，它们会直接进入阻塞队列。
                runtime_Semrelease(&m.sema, true, 1)
        }
}

Lock 细节

如果一开始 Mutex.state 是一个空值状态，那么 CAS 更新 mutexLocked 标志位会直接成功，相当于上锁了。那么其他 goroutine 想要上锁就要走 slow path 了。

// sync/mutex.go

// Lock locks m.
// If the lock is already in use, the calling goroutine
// blocks until the mutex is available.
func (m *Mutex) Lock() {
        // Fast path: grab unlocked mutex.
        if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
                if race.Enabled {
                        race.Acquire(unsafe.Pointer(m))
                }
                return
        }
        // Slow path (outlined so that the fast path can be inlined)
        m.lockSlow()
}

这里代码细节比较多，我们直接查看中文注释~

// sync/mutex.go

func (m *Mutex) lockSlow() {
        var waitStartTime int64
	// 所有刚进入 slow path 的 goroutine 都会以正常模式运行
	// 只有出现阻塞了超过 1ms 的情况，才会将 starving = true
        starving := false
        awoke := false
        iter := 0
        old := m.state
        for {
		// 正常模式下（非 Starving） 的时候，新到达的 goroutine 会尝试
		// 空转 4 次左右。如果还是 Locked 状态 或者 出现了 Starving 状态，
		// goroutine 会尝试释放执行单元，进入阻塞状态。
                if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
			// 如果阻塞队列非空，那么应该尝试设置上 Woken 状态。
			// 用来通知 Unlock 不要做唤醒动作，让当前的 goroutine 去竞争锁。
                        if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
                                atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
                                awoke = true
                        }
                        runtime_doSpin()
                        iter++
                        old = m.state
                        continue
                }
                new := old
                // 如果已经处于 Starving 状态了，那么新到达的 goroutine 就不要
		// 去竞争锁了。
                if old&mutexStarving == 0 {
                        new |= mutexLocked
                }
		// 如果当前(已经上锁|处于 Starving) 状态，那么(新到达|被唤醒) 
		// goroutine 应该变成阻塞状态。
                if old&(mutexLocked|mutexStarving) != 0 {
                        new += 1 << mutexWaiterShift
                }
		//「长时间阻塞 - 被唤醒了还拿不到锁」goroutine 会设置上 Starving。
		// 希望在释放锁的时候，优先唤醒自己。
                if starving && old&mutexLocked != 0 {
                        new |= mutexStarving
                }
		// 如果是当前 goroutine 设置上了 woken 状态，那么在尝试获得锁的时候，
		// 应该去掉该标记位。
                if awoke {
                        if new&mutexWoken == 0 {
                                throw("sync: inconsistent mutex state")
                        }
                        new &^= mutexWoken
                }
                if atomic.CompareAndSwapInt32(&m.state, old, new) {
			// 1. old&(mutexLocked|mutexStarving) = 10B
			//    锁已经释放，但正在唤醒「设置 Starving」 goroutine，
			//    当前 goroutine 拿不到锁；
			//
			// 2. old&(mutexLocked|mutexStarving) = 01B
			//    锁还没被释放，当前 goroutine 拿不到锁；
			//
			// 3. old&(mutexLocked|mutexStarving) = 11B
			//    被唤醒的 goroutine 刚更新成 Starving 状态，
			//    当前 goroutine 拿不到锁；
			//
			// 4. old&(mutexLocked|mutexStarving) = 0
			//    正好遇到释放锁，运气不错，new 值拿到锁，退出。
                        if old&(mutexLocked|mutexStarving) == 0 {
                                break // locked the mutex with CAS
                        }
                        queueLifo := waitStartTime != 0
                        if waitStartTime == 0 {
                                waitStartTime = runtime_nanotime()
                        }
			// 「被唤醒过 - 但竞争失败」的 goroutine 都采用 LIFO 
			// 头插法入队，即插队。
			//
			// runtime_SemacuireMutex 将当前 goroutine 设置成阻塞态
                        runtime_SemacquireMutex(&m.sema, queueLifo, 1)

                        // 被唤醒之后继续执行 
                        starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
                        old = m.state

			// old&mutexStarving != 0 说明当前 goroutine 已经拿到锁。
			// 但这个时候 Mutex.state 相应标记位还没更新。
                        if old&mutexStarving != 0 {
				// 在 Starving 状态下，Unlock 只负责唤醒，并不
				// 会更新 Mutex.state 状态。如果状态被修改成
				// mutexLocked，导致不一致，应该 panic。
                                if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
                                        throw("sync: inconsistent mutex state")
                                }
                                // 更新 mutexLocked 以及对阻塞数目减一。
                                delta := int32(mutexLocked - 1<<mutexWaiterShift)
				// 如果 Starving 状态不清理，那么每次 Unlock
				// 都会直接唤醒阻塞队列里的。
				// 
				// 毕竟 Starving 会让新到达的 goroutine 直接放
				// 弃竞争，解决某些「阻塞太久 goroutine」
				// 获得锁的问题，但也浪费了新到达的 goroutine
				// 的执行时间。
				//
				// 如果发现阻塞队列里的 goroutine 并没有达到
				// Starving 设置阈值，那么 应该清理掉 Starving
				// 标记位。
                                if !starving || old>>mutexWaiterShift == 1 {
                                        delta -= mutexStarving
                                }
                                atomic.AddInt32(&m.state, delta)
                                break
                        }
			// 属于正常唤醒，Unlock 已经帮忙设置上 mutexWoken 标记
			// 和 对阻塞数目减一。
                        awoke = true
                        iter = 0
                } else {
                        old = m.state
                }
        }

        if race.Enabled {
                race.Acquire(unsafe.Pointer(m))
        }
}

小结

sync.Mutex 整体代码量不多，其中很多细节都被 runtime.sync_runtime_SemacquireMutex 和 runtime.sync_runtime_Semrelease 函数屏蔽了，后面有时间会更新这部分的代码分析。

可以同时对一个 go string 进行读写操作吗？

Sat, 30 May 2020 00:00:00 -0400

写过 Go 代码的同学都知道，在程序内启动多个 goroutine 处理任务是很常见的事情，启动一个 goroutine 要比启动一个线程简单的多。当多个 goroutine 同时处理同一份数据时，我们应该在代码中加入同步机制，保证多个 goroutine 按照一定顺序来访问数据，不然就会出现 data race。最常见的例子如下，同时写操作 map 数据会导致程序 panic，即使操作的是不同 key：

// example 1

package main

func main() {
        for {
                c := make(chan bool)
                m := make(map[string]string)
                go func() {
                        m["1"] = "a" // First conflicting access.
                        c <- true
                }()
                m["2"] = "b" // Second conflicting access.
                <-c
        }
}

那么下面的代码也会 panic 吗？

// example 2
//
1  package main
2
3  import "sync"
4
5  func main() {
6          var wg sync.WaitGroup
7
8          for {
9                  var s string
10                  var r []byte
11
12                  wg.Add(2)
13
14                  // goroutine 1: update string s
15                  go func() {
16                          defer wg.Done()
17                          s = "panic?"
18                  }()
19
20                  // goroutine 2: read string s
21                  go func() {
22                          defer wg.Done()
23                          r = append(r, s...)
24                  }()
25
26                  wg.Wait()
27          }
28  }

答案稍后揭晓，现在先看下 Go Runtime 下是如何描述 string 数据: 一个 string 有两个字段，str 用来存储长度为 len 的字符串。那么 string 的赋值会是原子操作吗？

// https://github.com/golang/go/tree/release-branch.go1.13/src/runtime/string.go

type stringStruct struct {
        str unsafe.Pointer
        len int
}

// 为了防止编译器优化带来影响，需要在下面的代码里引入 print 和额外的 goroutine，
// 保证在汇编结果里就可以看到实际的字符串赋值语句了。
//
// cat -n main.go
1  package main
2
3  func main() {
4          var s string
5          go func() {
6                  s = "I am string"
7          }()
8          print(s)
9  }

为了查看具体 string 赋值代码，这里需要使用 go tool compile -S ./main.go 来获取汇编结果。在下面的输出结果中，s = "I am string" 赋值语句会被拆成两部分: 先更新字符串的长度 len 字段, 再更新具体的字符串内容到 str 字段。

"".main.func1 STEXT size=89 args=0x8 locals=0x8
	0x0000 00000 (./main.go:5)      TEXT    "".main.func1(SB), ABIInternal, $8-8
	0x0000 00000 (./main.go:5)      MOVQ    (TLS), CX
	0x0009 00009 (./main.go:5)      CMPQ    SP, 16(CX)
	0x000d 00013 (./main.go:5)      JLS     82
	0x000f 00015 (./main.go:5)      SUBQ    $8, SP
	0x0013 00019 (./main.go:5)      MOVQ    BP, (SP)
	0x0017 00023 (./main.go:5)      LEAQ    (SP), BP
	0x001b 00027 (./main.go:5)      FUNCDATA        $0, gclocals·1a65e721a2ccc325b382662e7ffee780(SB)
	0x001b 00027 (./main.go:5)      FUNCDATA        $1, gclocals·69c1753bd5f81501d95132d08af04464(SB)
	0x001b 00027 (./main.go:5)      FUNCDATA        $2, gclocals·39825eea4be6e41a70480a53a624f97b(SB)
	0x001b 00027 (./main.go:6)      PCDATA  $0, $1
	0x001b 00027 (./main.go:6)      PCDATA  $1, $1

	  0x001b 00027 (./main.go:6)      MOVQ    "".&s+16(SP), DI
先更新长度  0x0020 00032 (./main.go:6)      MOVQ    $11, 8(DI)

	0x0028 00040 (./main.go:6)      PCDATA  $0, $-2
	0x0028 00040 (./main.go:6)      PCDATA  $1, $-2
	0x0028 00040 (./main.go:6)      CMPL    runtime.writeBarrier(SB), $0
	0x002f 00047 (./main.go:6)      JNE     68

再赋值内容  0x0031 00049 (./main.go:6)      LEAQ    go.string."I am string"(SB), AX
	  0x0038 00056 (./main.go:6)      MOVQ    AX, (DI)

	0x003b 00059 (./main.go:7)      MOVQ    (SP), BP
	0x003f 00063 (./main.go:7)      ADDQ    $8, SP
	0x0043 00067 (./main.go:7)      RET
	0x0044 00068 (./main.go:6)      LEAQ    go.string."I am string"(SB), AX
	0x004b 00075 (./main.go:6)      CALL    runtime.gcWriteBarrier(SB)
	0x0050 00080 (./main.go:6)      JMP     59
	0x0052 00082 (./main.go:6)      NOP
	0x0052 00082 (./main.go:5)      PCDATA  $1, $-1
	0x0052 00082 (./main.go:5)      PCDATA  $0, $-1
	0x0052 00082 (./main.go:5)      CALL    runtime.morestack_noctxt(SB)
	0x0057 00087 (./main.go:5)      JMP     0

NOTE: runtime.xxxBarrier 是 Go 编译器为垃圾回收生成的代码，可以忽略。

回到一开始的问题 example 2 代码片段，r = append(r, s...) 采用 memmove 方法从字符串 s 拷贝 len(s) 个字节到 r 里。由于 s = "panic?" 赋值和 append 读操作是同时进行：假设 s.len 已经被更新成 6 ，但是 s.str 还是 nil 状态，这个时候正好执行了 append 的操作，直接读取空指针必定会 panic。

// 其中一种可能的执行顺序

goruntine 1: set s.len = len("panic?") # 6 字节
goruntine 2: r = append(r, s...)       # 将从 s.str 中拷贝 6 字节，但 s.str = nil
goroutine 1: set s.str = "panic?"

// part of example 2
//
(...)

14                  // goroutine 1: update string s
15                  go func() {
16                          defer wg.Done()
17                          s = "panic?"
18                  }()
19
20                  // goroutine 2: read string s
21                  go func() {
22                          defer wg.Done()
23                          r = append(r, s...)
24                  }()

(...)

除了 append 这种场景以外，字符串的比较同样需要 len 和 str 一致。如果在执行读操作时，str 实际存储的数据长度比 len 短，程序就会 panic。所以避免 data race 最好方式就是采用合适的同步机制，这来自 Go 团队给出的最佳实践：

Programs that modify data being simultaneously accessed by multiple goroutines must serialize such access.

from https://golang.org/ref/mem Advice section

在线看 O'Reilly 动物新书指南

Sat, 21 Mar 2020 00:00:00 -0400

想当初，为了看 Operating Systems: Three Easy Pieces 和 A Philosophy of Software Design 原版技术书，还特别麻烦了朋友从国外人肉带回来，成本极高。但如果等国内出版社引进，就会出现时间跨度太大没法尝鲜；加上翻译水平参差不齐，等待中文版的路子基本上行不通。为了解决这个尴尬问题，最近找到了一个比较实惠看国外原版书籍的方式：ACM Professional Membership。

ACM Professional Membership 会员权益有很多，其中有一项是：

Learning Center with resources for lifelong learning, including online courses targeted toward essential IT skills and popular certifications; online books & videos from Skillsoft®, online books from O’Reilly®, Morgan Kaufmann and Syngress; videos and webinars on hot topics, presented by today’s innovators

会员可以享受学习平台，其中包含了 O’Reilly online books。平时在网上买技术书籍，基本上都能看到 O’Reilly 动物封面书籍，比如 Site Reliability Engineering。这个出版社覆盖的书籍比较多，基本上能满足我大部分阅读需求。本着怀疑的态度看这个权益，没想到尝试之后，真香。

ACM Professional Membership 会员直接注册的话，需要 99 美金一年。但是 ACM 还提供了 Special rates for Professionals in economically developing countries 优惠。在页面上你会看见 China 字样，点击之后会发现一年基本包才 170 RMB，真的优惠不少。

ACM 主页有 Join 链接，点击就可以看到 Special rates for Professionals in economically developing countries。

只要有本科学士学位或者同等教育，或者两年 IT 领域的工作经历就可以申请会员了。我在注册过程中，没有遇到需要提供相关证明的要求，基本上填完信息、付款完毕就申请成功了。但是付款页面做的实在太简陋了，用信用卡看着就不安全，再加上邮寄付款方式不方便，所以最后选择了 Paypal 支付。注册完毕之后，申请 ACM Web Account 就大功告成了，如何登陆 O’Reilly 可以查看学习平台使用指南。

在家使用了一个月，在电脑和手机端都可以登陆，除了页面搜索响应速度不快以外，基本上体验还是很不错。最重要的是新书基本都可以看到，就像最新上架的 Software Engineering at Google。

言而总之，一言以蔽之，这付费订阅体验真的很好！

Hola Barcelona

Sun, 02 Jun 2019 00:00:00 +0000

前段时间因为 KubeCon 演讲去了趟西班牙-巴塞罗那，忙里偷闲，感受了下西方文化。

不再是「白本」

5.18 号从杭州出发，途径香港转机到巴塞罗那。飞机上的娱乐设施还算丰富，「海王」、「绿皮书」等新片都可以观看到。十几个小时的飞机总不能一直看电影，还得兼顾倒时差的任务。

之前没有调整时差的经验，加上平时作息比较规律，十三个小时的飞行过程里相对属于清醒状态。网络要收费，印象中比较贵，基本上干不了别的事情，除了看电影就是睡觉。如果经济允许，可以考虑升舱，坐经济舱飞十几小时简直了。到达巴塞罗那是当地时间早上8点，天气还算不错，就是有点过于「凉快」，完全没有夏天的感觉。上了摆渡车，直奔海关。

当地的海关工作人员整体都不严肃，有些还带着耳机工作，有点不可思议。轮到我的时候，那位海关小哥看了我半天，感觉不像，盖章的时候特别犹豫，而且盖完章之后他应该是后悔了，还用类似验钞机的东西反复扫描我的签注，最后才说「Wei Fu, Welcome」。

说句实在话，我当时的反应是这签证不会特么是假的吧，因为从广州签证处提交申请到拿到签证只花了「三天」，申请港澳通行证都没有那么快。还好，有惊无险。

骑行友好的街道

虽然没有游玩整个巴塞罗那，但是可以感觉到城市的大部分街道都是单行道。我在早高峰的时候打过车，车多但不算堵。

说到打车，这里的打车算是一件高消费的服务了。我没有用 Uber/MyTaxi 软件打车，大部分都是通过酒店来约车，而这种约车是需要收调度费，大概2-3 欧左右吧。接近4公里左右的路程要 15 欧，贵！

可能是养一辆车的费用比较高吧，这座城市的摩托车特别多，几乎随处可见。比较有意思的是摩托车车锁，他们的车锁是锁车把和车身，基本上不需要下蹲去锁车。

虽然北京也有自行车道，但是大部分都被私家车占用了，对骑行的人来说极度不友好。这边的街道基本是两车道配一个自行车道，而汽车道和自行车道基本上严格分开，有些地方还有隔离带，对爱骑车的人来说真是太幸福了。

如果你打开 Mobike，估计还会有惊喜哦。

地铁，还不算太破

我住的酒店离地铁站不远，走几个街头就可以到达地铁站。在长达 15 个小时日照时间里，在拓展区里步行还算安全，也比较舒服。

随处可见的遛狗人士，转角处的饮酒闲谈，还有无法欣赏的涂鸦。建筑都相对破旧，估计这十几年的变化也就是街上跑的私家车了。

不管是去日本，还是来到巴塞罗那，这边的地铁和火车一样，发车和到达时间点都是严格规定好的。这有个好处就是，每天都可以踩点出发。

整个城市的地铁覆盖范围还是比较大，就是不同的区域由不同的公司运营，换乘基本上要出站重新购票了。如果不买套票，单程票就要 2.2 欧，贵的一匹。刷票进站后，给人感觉就是简陋，但不算太破。

语言？No English

巴塞罗那选择的时区和德国好像是一样的，都是东一区。在夏天，他们日照时间有 15 小时，到晚上 9 点天还是亮的。

因为长时间日照的原因，他们物产是比较丰富的。但是想不明白的是，他们这边的特产是「西班牙火腿」。这火腿是腌制好几年而成，吃的时候切的越薄口感越好。主要这是生肉。。。

和当地的「潮州佬」店主聊，他们当地喜欢吃「生」，日料店相对中餐而言要受欢迎些，估计是好吃「生」的食材吧。尝过 Tapa，也看过所谓的海鲜饭，还是觉得国内的菜还吃。

出去吃饭更要命的是，点菜的时候没有图片，加上有些还没有英文注释，基本就瞎了。看不懂可以问吧，但是这边的人不太会说英语，也不愿意说。你可以想象下，机场里的工作人员会直接对你「No English」。这体验真的比去日本还糟糕。

一直在「修」

城市比较小，到达的第一天就小转了一圈。

因为加泰罗尼亚要闹独立，涂鸦就是这边的独特的风景线。从酒店走到港口，街道上的店铺都没开门。问了下当地国人，说这边的人比较懒，周末基本都享受去了，开便利店的基本都是非本地人。

一路上都有海鸥到处飞，海鸥也不怕人，基本给啥吃啥，爆米花都吃！

在港口溜达一会，就去看世界上最著名的「烂尾楼」 - 「圣家族大教堂」。这座大教堂修了 100 年，因为修的时间是在太长了，不知道是不是中间换了几个设计师，教堂每个角度的风格都不太一样。不过这也算是巴塞罗那著名景点了，只可惜当天去的时候没有门票了，没能进去。

最后

这次出国没准备攻略，基本上是很佛系地逛了下，剩下大部分时间都在准备演讲内容。不过怎样，出远门才觉得国内是真TM方便。

工作三年

Fri, 13 Apr 2018 00:00:00 +0000

不知不觉就过了三年，但是我还能很清楚地记得当时签卖身契的场景，只能说毕业之后时间过的飞起。这三年没写过什么年度总结，今天打算矫情一把，记下流水账。

Vimer

有一次参加罗老师开发环境的分享会后，我就开始迷上 vim，并结束了 IDE/Sublime 之间的摇摆。从实用角度看，IDE 有着开箱即用的特点，这的确让人无法抗拒。但在平时的工作里，不同语言之间切换是常有的事，而且经常远程调试、常年沉浸在 Terminal 的我，vim 作为编辑器是一个不错的选择。加上韩国小哥 junegunn 开源神器 fzf ，解决了 vim 全文检索巨卡的痛点，这让我毫不犹豫地坚持使用 vim。没试过 fzf 的朋友不妨试试！

我在习惯 HJKL 的同时，也在尝试回馈社区。还记得刚用 fzf.vim 的时候，当时的全文检索没有预览功能，相比于 Sublime，几乎没法用。所以在参加完公司第二个 Hackathon 之后的那个周末提了人生的第一个 PR。在这期间和韩国小哥 junegunn 来来回回讨论了快一个月，虽然最后失败了，但是我很享受这期间的沟通过程，毕竟能把自己的想法表达清楚是一件难得的事，因为非实时的沟通一旦出现理解偏差，时间成本将会急速上升。

在后来使用了 vim-delve 插件，并帮助作者修复了几个 bug，也算是回馈社区了~

MIT 6.828

在 16 年年初，非计算机专业的我选择了恶补操作系统：MIT 6.828。

前前后后花了三个周末完成所有基本要求。课程设计者虽然尽可能地避免了琐碎的硬件操作，但是这三个周末还是非常的虐，毕竟 x86 架构有很多历史包袱，需要阅读 Intel x86 的开发文档。。。这三个周末完成的玩具内核让我重新认识了操作系统，对我后续的工作帮助极大。

不过你们会相信恶补的原因只是想知道 fork 怎么做到两个返回值吗？

Gopher

语言切换算是这三年里最大的变化吧。为了看 Docker 的代码而接触 Golang，但是在16年年底的时候公司并没有项目让我去实践，当时的我只能自己啃代码，等到真正实践的时候也差不多到17年年中了。

去年七八月我偶然发现 PingCAP 有赠马克杯的 TiDB 重构活动，很幸运的是提的三个 PR 都被接受了，这也是我第一次在 Github 上贡献代码。再后来就是 Pouch，因为对容器的喜爱吧，几乎大部分的空闲时间都参与到 Pouch 上来了。

除了代码以外，还因为 Golang 开源项目结识了一些朋友，不得不说真是名副其实的 G**hub。

我的 2018

以上是过去三年来影响最大的三件事，不管怎样，希望还能像过去三年那样保持好奇的心吧。

Goroutine Scheduler Overview

Tue, 06 Feb 2018 00:00:00 -0500

Goroutine 是 Golang 世界里的 Lightweight Thread 。

Golang 在语言层面支持多线程，代码可以通过 go 关键字来启动 Goroutine ，调用者不需要关心调用栈的大小，函数上下文等等信息就可以完成并发或者并行操作，加快了我们的开发速度。分析 Goroutine 调度有利于了解和分析 go binary 的工作状况，所以接下来的内容将分析 runtime 中关于 Goroutine 调度的逻辑。

以下内容涉及到的代码是基于 go1.9rc2 版本。

1. Scheduler Structure

整个调度模型由 Goroutine/Processor/Machine 以及全局调度信息 sched 组成。

                   Global Runnable Queue

                          runqueue
                ----------------------------
                 | G_10 | G_11 | G_12 | ...
                ----------------------------

                                        P_0 Local Runnable Queue
                +-----+      +-----+       ---------------
                | M_3 | ---- | P_0 |  <===  | G_8 | G_9 |
                +-----+      +-----+       ---------------
                                |
                             +-----+
                             | G_3 |  Running
                             +-----+

                                        P_1 Local Runnable Queue
                +-----+      +-----+       ---------------
                | M_4 | ---- | P_1 |  <===  | G_6 | G_7 |
                +-----+      +-----+       ---------------
                                |
                             +-----+
                             | G_5 |  Running
                             +-----+

1.1 Goroutine

Goroutine 是 Golang 世界里的 线程 ，同样也是可调度的单元。

// src/runtime/runtime2.go
type g struct {
        ....
        m       *m
        sched gobuf
        goid   int64
        ....
}

type gobuf struct {
        sp   uintptr
        pc   uintptr
        ....
}

runtime 为 Goroutine 引入了类似 PID 的属性 goid ，使得每一个 Goroutine 都有全局唯一的 goid 标识。不过官方并没有提供接口能直接访问当前 Goroutine 的 goid，在这种情况下我们可以通过汇编或者取巧的方式得到 goid，有些第三方 package 会利用 goid 做一些有趣的事情，比如 Goroutine local storage ，后面会介绍 runtime 是如何生成唯一的 goid 。

在调度过程中，runtime 需要 Goroutine 释放当前的计算资源，为了保证下次能恢复现场，执行的上下文现场（指令地址和 Stack Pointer 等）将会存储在 gobuf 这个数据结构中。

整体来说，Goroutine 仅代表任务的内容以及上下文，并不是具体的执行单元。

1.2 Machine

Machine 是 OS Thread，它负责执行 Goroutine。

// src/runtime/runtime2.go

type m struct {
        ....
        g0      *g     // goroutine with scheduling stack
        curg    *g     // current running goroutine

        tls     [6]uintptr // thread-local storage (for x86 extern register)
        p       puintptr // attached p for executing go code (nil if not executing go code)
        ....
}

runtime 在做调度工作或者和当前 Goroutine 无关的任务时，Golang 会切换调用栈来进行相关的任务，就好像 Linux 的进程进入系统调用时会切换到内核态的调用栈一样，这么做也是为了避免影响到调度以及垃圾回收的扫描。

Machine 一般会调用 systemstack 函数来切换调用栈。从名字可以看出，Golang 对外部 go code 的调用栈称之为 user stack ，而将运行核心 runtime 部分代码的调用栈称之为 system stack。 Machine 需要维护这两个调用栈的上下文，所以 m 中 g0 用来代表 runtime 内部逻辑，而 curg 则是我们平时写的代码，更多详情可以关注 src/runtime/HACKING.md.

因为调用栈可以来回地切换，Machine 需要知道当前运行的调用栈信息，所以 Golang 会利用 Thread Local Storage 或者指定寄存器来存储当前运行的 g。 settls 汇编代码会将 g 的地址放到 m.tls 中，这样 Machine 就可以通过 getg 取出当前运行的 Goroutine。

不同平台 settls 的行为有一定差别。

// src/runtime/sys_linux_amd64.s

// set tls base to DI
TEXT runtime·settls(SB),NOSPLIT,$32
#ifdef GOOS_android
        // Same as in sys_darwin_386.s:/ugliness, different constant.
        // DI currently holds m->tls, which must be fs:0x1d0.
        // See cgo/gcc_android_amd64.c for the derivation of the constant.
        SUBQ    $0x1d0, DI  // In android, the tls base·
#else
        ADDQ    $8, DI  // ELF wants to use -8(FS)
#endif
        MOVQ    DI, SI
        MOVQ    $0x1002, DI     // ARCH_SET_FS
        MOVQ    $158, AX        // arch_prctl
        SYSCALL
        CMPQ    AX, $0xfffffffffffff001
        JLS     2(PC)
        MOVL    $0xf1, 0xf1  // crash
        RET

// src/runtime/stubs.go

// getg returns the pointer to the current g.
// The compiler rewrites calls to this function into instructions
// that fetch the g directly (from TLS or from the dedicated register).
func getg() *g

// src/runtime/go_tls.h 

#ifdef GOARCH_amd64
#define get_tls(r)      MOVQ TLS, r
#define g(r)    0(r)(TLS*1)
#endif

但是 Machine 想要执行一个 Goroutine，必须要绑定 Processor。

runtime 内部有些函数执行时会直接绑定 Machine，并不需要 Processor，比如 sysmon 。

1.3 Processor

Processor 可以理解成处理器，它会维护着本地 Goroutine 队列 runq ，并在新的 Goroutine 入队列时分配唯一的 goid。

type p struct {
        ...
        m           muintptr   // back-link to associated m (nil if idle)

        // Cache of goroutine ids, amortizes accesses to runtime·sched.goidgen.
        goidcache    uint64
        goidcacheend uint64

        // Queue of runnable goroutines. Accessed without lock.
        runqhead uint32
        runqtail uint32
        runq     [256]guintptr
        ...
}

Processor 的数目代表着 runtime 能同时处理 Goroutine 的数目，GOMAXPROCS 环境变量是用来指定 Processor 的数目，默认状态会是 CPU 的个数。

也正是因为 Processor 的存在，runtime 并不需要做一个集中式的 Goroutine 调度，每一个 Machine 都会在 Processor 本地队列、Global Runnable Queue 或者其他 Processor 队列中找 Goroutine 执行，减少全局锁对性能的影响，后面会对此展开说明。

1.4 全局调度信息 sched

全局调度信息 sched 会记录当前 Global Runnable Queue、当前空闲的 Machine 和空闲 Processor 的数目等等。

后面说明这 goidgen 和 nmspinning 两个字段的作用。

// src/runtime/runtime2.go

var (
        ...
        sched      schedt
        ...
)

type schedt struct {
        // accessed atomically. keep at top to ensure alignment on 32-bit systems.
        goidgen  uint64

        lock mutex

        midle        muintptr // idle m's waiting for work
        nmidle       int32    // number of idle m's waiting for work
        maxmcount    int32    // maximum number of m's allowed (or die)

        pidle      puintptr // idle p's
        npidle     uint32
        nmspinning uint32 // See "Worker thread parking/unparking" comment in proc.go.

        // Global runnable queue.
        runqhead guintptr
        runqtail guintptr
        runqsize int32
        ....
}

2. Create a Goroutine

下面那段代码非常简单，在 main 函数中产生 Goroutine 去执行 do() 这个函数。

➜  main cat -n main.go
     1  package main
     2
     3  func do() {
     4          // nothing
     5  }
     6
     7  func main() {
     8          go do()
     9  }

我们编译上述代码并反汇编看看 go 关键字都做了什么。可以看到源代码的第 8 行 go do() 编译完之后会变成 runtime.newproc 方法，下面我们来看看 runtime.newproc 都做了些什么。

➜  main uname -m -s
Linux x86_64
➜  main go build
➜  main go tool objdump -s "main.main" main
TEXT main.main(SB) /root/workspace/main/main.go
  main.go:7             0x450a60                64488b0c25f8ffffff      MOVQ FS:0xfffffff8, CX
  main.go:7             0x450a69                483b6110                CMPQ 0x10(CX), SP
  main.go:7             0x450a6d                7630                    JBE 0x450a9f
  main.go:7             0x450a6f                4883ec18                SUBQ $0x18, SP
  main.go:7             0x450a73                48896c2410              MOVQ BP, 0x10(SP)
  main.go:7             0x450a78                488d6c2410              LEAQ 0x10(SP), BP
  main.go:8             0x450a7d                c7042400000000          MOVL $0x0, 0(SP)
  main.go:8             0x450a84                488d05e5190200          LEAQ 0x219e5(IP), AX
  main.go:8             0x450a8b                4889442408              MOVQ AX, 0x8(SP)
  main.go:8             0x450a90                e88bb4fdff              CALL runtime.newproc(SB)  <==== I'm here.
  main.go:9             0x450a95                488b6c2410              MOVQ 0x10(SP), BP
  main.go:9             0x450a9a                4883c418                ADDQ $0x18, SP
  main.go:9             0x450a9e                c3                      RET
  main.go:7             0x450a9f                e88c7dffff              CALL runtime.morestack_noctxt(SB)
  main.go:7             0x450aa4                ebba                    JMP main.main(SB)

2.1 创建 do() 的执行上下文

平时写代码的时候会发现，Goroutine 执行完毕之后便消失了。那么 do() 这个函数执行完毕之后返回到哪了呢？

➜  main go tool objdump -s "main.do" main
TEXT main.do(SB) /root/workspace/main/main.go
  main.go:5             0x450a50                c3                      RET

根据 Intel 64 IA 32 开发指南上 Chaptor 6.3 CALLING PROCEDURES USING CALL AND RET 的说明，RET 会将栈顶的指令地址弹出到 IP 寄存器上，然后继续执行 IP 寄存器上的指令。为了保证 Machine 执行完 Goroutine 之后，能够正常地完成一些清理工作，我们需要在构建 Goroutine 的执行上下文时指定 RET 的具体地址。

下面的代码段会将准备好的调用栈内存保存到 newg.sched 中，其中 gostartcallfn 函数会把 do() 函数添加到 newg.sched.pc ，并将 goexit 函数地址推入栈顶 newg.sched.sp。所以 Goroutine 执行完毕之后，Machine 会跳到 goexit 函数中做一些清理工作。

// src/runtime/proc.go @ func newproc1

if narg > 0 {
        memmove(unsafe.Pointer(spArg), unsafe.Pointer(argp), uintptr(narg)
        ....
}

newg.sched.sp = sp
newg.sched.pc = funcPC(goexit) + sys.PCQuantum // +PCQuantum so that previous instruction is in same function
newg.sched.g = guintptr(unsafe.Pointer(newg))
gostartcallfn(&newg.sched, fn)
newg.gopc = callerpc
newg.startpc = fn.fn

想了解 Intel 指令的更多细节，请查看 Intel® 64 and IA-32 Architectures Developer’s Manual: Vol. 1。

2.2 全局唯一的 goid

除了创建执行上下文以外，runtime 还会为 Goroutine 指定一个全局唯一的 id。

// src/runtime/proc.go

const (
        // Number of goroutine ids to grab from sched.goidgen to local per-P cache at once.
        // 16 seems to provide enough amortization, but other than that it's mostly arbitrary number.
        _GoidCacheBatch = 16
)

// src/runtime/proc.go @ func newproc1

if _p_.goidcache == _p_.goidcacheend {
        // Sched.goidgen is the last allocated id,
        // this batch must be [sched.goidgen+1, sched.goidgen+GoidCacheBatch].
        // At startup sched.goidgen=0, so main goroutine receives goid=1.
        _p_.goidcache = atomic.Xadd64(&sched.goidgen, _GoidCacheBatch)
        _p_.goidcache -= _GoidCacheBatch - 1
        _p_.goidcacheend = _p_.goidcache + _GoidCacheBatch
}
newg.goid = int64(_p_.goidcache)
_p_.goidcache++

全局调度信息 sched.goidgen 是专门用来做发号器，Processor 每次可以从发号器那拿走 _GoidCacheBatch 个号，然后内部采用自增的方式来发号，这样就保证了每一个 Goroutine 都可以拥有全局唯一的 goid。

从全局调度信息那里取号的时候用原子操作来保证并发操作的正确性，而内部发号时却采用非原子操作，这是因为一个 Processor 只能被一个 Machine 绑定上，所以这里 _p_.goidcache 自增不需要要原子操作也能保证它的正确性。

2.3 Local vs Global Runnable Queue

当 Goroutine 创建完毕之后，它是放在当前 Processor 的 Local Runnable Queue 还是全局队列里？

runqput 这个函数会尝试把 newg 放到本地队列上，如果本地队列满了，它会将本地队列的前半部分和 newg 迁移到全局队列中。剩下的事情就等待 Machine 自己去拿任务了。

// src/runtime/proc.go @ func newproc1

runqput(_p_, newg, true)

2.4 小结

看到这里，一般都会有以下几个疑问：

main 函数是不是也是一个 Goroutine ？
Machine 怎么去取 Goroutine 来执行?
goexit 做完清理工作之后就让 Machine 退出吗？还是继续使用这个 Machine?

那么就继续往下读吧~

3. main is a Goroutine

我们写的 main 函数在程序启动时，同样会以 Goroutine 身份被 Machine 执行，下面会查看 go binary 启动时都做了什么。

➜  main uname -m -s
Linux x86_64
➜  main go build --gcflags "-N -l"
➜  main gdb main
(gdb) info file
Symbols from "/root/workspace/main/main".
Local exec file:
        `/root/workspace/main/main', file type elf64-x86-64.
        Entry point: 0x44bb80
        0x0000000000401000 - 0x0000000000450b13 is .text
        0x0000000000451000 - 0x000000000047a6bc is .rodata
        0x000000000047a7e0 - 0x000000000047afd4 is .typelink
        0x000000000047afd8 - 0x000000000047afe0 is .itablink
        0x000000000047afe0 - 0x000000000047afe0 is .gosymtab
        0x000000000047afe0 - 0x00000000004a96c8 is .gopclntab
        0x00000000004aa000 - 0x00000000004aaa38 is .noptrdata
        0x00000000004aaa40 - 0x00000000004ab5b8 is .data
        0x00000000004ab5c0 - 0x00000000004c97e8 is .bss
        0x00000000004c9800 - 0x00000000004cbe18 is .noptrbss
        0x0000000000400fc8 - 0x0000000000401000 is .note.go.buildid
(gdb) info symbol 0x44bb80
_rt0_amd64_linux in section .text

入口函数是 _rt0_amd64_linux，需要说明的是，不同平台的入口函数名称会有所不同，全局搜索该方法之后，发现该方法会调用 runtime.rt0_go 汇编。

省去了大量和硬件相关的细节后，rt0_go 做了大量的初始化工作，runtime.args 读取命令行参数、runtime.osinit 读取 CPU 数目，runtime.schedinit 初始化 Processor 数目，最大的 Machine 数目等等。

除此之外，我们还看到了两个奇怪的 g0 和 m0 变量。m0 Machine 代表着当前初始化线程，而 g0 代表着初始化线程 m0 的 system stack，似乎还缺一个 p0 ？实际上所有的 Processor 都会放到 allp 里。runtime.schedinit 会在调用 procresize 时为 m0 分配上 allp[0] 。所以到目前为止，初始化线程运行模式是符合上文提到的 G/P/M 模型的。

大量的初始化工作做完之后，会调用 runtime.newproc 为 mainPC 方法生成一个 Goroutine。虽然 mainPC 并不是我们平时写的那个 main 函数，但是它会调用我们写的 main 函数，所以 main 函数是会以 Goroutine 的形式运行。

有了 Goroutine 之后，那么 Machine 怎么执行呢？

// src/runtime/asm_amd64.s

TEXT runtime·rt0_go(SB),NOSPLIT,$0
         ...

// set the per-goroutine and per-mach "registers"
        // save m->g0 = g0
        MOVQ    CX, m_g0(AX)
        // save m0 to g0->m
        MOVQ    AX, g_m(CX)

        ...
        CALL    runtime·args(SB)
        CALL    runtime·osinit(SB)
        CALL    runtime·schedinit(SB)

        // create a new goroutine to start program
        MOVQ    $runtime·mainPC(SB), AX        // entry
        PUSHQ   AX
        PUSHQ   $0      // arg size
        CALL    runtime·newproc(SB)

        ...
        // start this M
        CALL    runtime·mstart(SB)  <=== I'm here!

        MOVL    $0xf1, 0xf1  // crash
        RET

4. Machine — Work Stealing

在上一节查看 rt0_go 汇编代码的时候，发现最后一段代码 CALL runtime.mstart(SB) 是用来启动 Machine。

因为在 Golang 的世界里，任务的执行需要 Machine 本身自己去获取。每个 Machine 运行前都会绑定一个 Processor，Machine 会逐步消耗完当前 Processor 队列。为了防止某些 Machine 没有事情可做，某些 Machine 忙死，所以 runtime 会做了两件事：

当前 Processor 队列已满，Machine 会将本地队列的部分 Goroutine 迁移到 Global Runnable Queue 中;
Machine 绑定的 Processor 没有可执行的 Goroutine 时，它会去 Global Runnable Queue、Net Network 和其他 Processor 的队列中抢任务。

这种调度模式叫做 Work Stealing。

4.1 如何执行 Goroutine？

// src/runtime/proc.go

func mstart() {
        ...
        } else if _g_.m != &m0 {
                acquirep(_g_.m.nextp.ptr()) // 绑定 Processor
                _g_.m.nextp = 0
        }
        schedule()
}

mstart() => schedule() => execute() => xxx() => goexit()

runtime.mstart 函数会调用 schedule 函数去寻找可执行的 Goroutine，查找顺序大致是:

Local Runnable Queue
Global Runnable Queue
Net Network
Other Processor’s Runnable Queue

需找可执行的 Goroutine 的逻辑都在 findrunnable 里。

找到任何一个可执行的 Goroutine 之后，会调用 execute 去切换到 g.sched 相应的调用栈，这样 Machine 就会执行我们代码里创建 Goroutine。

执行完毕之后会 RET 到 goexit, goexit 会调用 goexit0 进行清理工作，然后再进入 schedule 模式。如果这个时候释放了当前 Machine，那么每次执行 Goroutine 都要创建新的 OS-Thread，这样的代价略大。所以 Machine 会不断地拿任务执行，直到没有任务。当 Machine 没有可执行的任务时，它会在 findrunnable 中调用 stopm 进入休眠状态。

那么谁来激活这些休眠状态的 Machine ？

4.2 Wake Up

常见的激活时机就是新的 Goroutine 创建出来的时候。我们回头看看 runtime.newproc 返回前都做了什么。

// src/runtime/proc.go @ func newproc1

if atomic.Load(&sched.npidle) != 0 && atomic.Load(&sched.nmspinning) == 0 && runtimeInitTime != 0 {
        wakep()
}

当 Machine 找不到可执行的 Goroutine 时，但是还在努力地寻找可执行的 Goroutine，这段时间它属于 spinning 的状态。它实在是找不到了，它才回释放当前 Processor 进入休眠状态。

atomic.Load(&sched.npidle) != 0 && atomic.Load(&sched.nmspinning) == 0 指的是有空闲的 Processor 而没有 spinning 状态的 Machine。这个时候可能是有休眠状态的 Machine，可能是程序刚启动的时候并没有足够的 Machine。当遇到这种情况，当前 Machine 会执行 wakep，让程序能快速地消化 Goroutine。

在初始化过程中，为 runtime.main 函数创建的第一个 Goroutine 并不需要调用 wakep，所以在该判断条件里 runtimeInitTime != 0 会失败。 runtimeInitTime 会在 runtime.main 函数中被赋值，表明正式开始执行任务啦。

wakep 首先会查看有没有空闲的 Machine，如果找到而且状态合理，那么就会激活它。如果没有找到，那么会创建一个新的 spinning Machine。

在 Golang 世界里，新创建的 Machine 可以认为它属于 spinning，因为创建 OS-Thread 有一定代价，一旦创建出来了它就要去干活。除此之外，Golang 创建新的线程并不会直接交付任务给它，而是让它调用 runtime.mstart 方法自己去找活做。

// src/runtime/proc.go

func wakep() {
        // be conservative about spinning threads
        if !atomic.Cas(&sched.nmspinning, 0, 1) {
                return
        }
        startm(nil, true)
}

func mspinning() {
        // startm's caller incremented nmspinning. Set the new M's spinning.
        getg().m.spinning = true
}

func startm(_p_ *p, spinning bool) {
        lock(&sched.lock)
        if _p_ == nil {
                _p_ = pidleget()
                if _p_ == nil {
                        unlock(&sched.lock)
                        if spinning {
                                // The caller incremented nmspinning, but there are no idle Ps,
                                // so it's okay to just undo the increment and give up.
                                if int32(atomic.Xadd(&sched.nmspinning, -1)) < 0 {
                                        throw("startm: negative nmspinning")
                                }
                        }
                        return
                }
        }
        mp := mget()
        unlock(&sched.lock)
        if mp == nil {
                var fn func()
                if spinning {
                        // The caller incremented nmspinning, so set m.spinning in the new M.
                        fn = mspinning
                }
                newm(fn, _p_)
                return
        }
        ...
        mp.spinning = spinning
        mp.nextp.set(_p_)
        notewakeup(&mp.park)
}

在 Linux 平台上，newm 会调用 newosproc 来产生新的 OS-Thread。

5. Preemptive

Machine 会在全局范围内查找 Goroutine 来执行，似乎还缺少角色去通知 Machine 释放当前 Goroutine，总不能执行完毕再切换吧。我们知道操作系统会根据时钟周期性地触发系统中断来进行调度，Golang 是用户态的线程调度，那它怎么通知 Machine 呢？

回忆上文, 提到了有些 Machine 执行任务前它并不需要绑定 Processor，它们都做什么任务呢？

// src/runtime/proc.go

func main() {
        ...
        systemstack(func() {
                newm(sysmon, nil)
        })
        ...
}

在 runtime.main 函数中会启动新的 OS-Thread 去执行 sysmon 函数。该函数会以一个上帝视角去查看 Goroutine/Machine/Processor 的运行情况，并会调用 retake 去让 Machine 释放正在运行的 Goroutine。

// src/runtime/proc.go

// forcePreemptNS is the time slice given to a G before it is
// preempted.
const forcePreemptNS = 10 * 1000 * 1000 // 10ms

func retake(now int64) uint32 {
        for i := int32(0); i < gomaxprocs; i++ {
                _p_ := allp[i]
                if _p_ == nil {
                        continue
                }
                pd := &_p_.sysmontick
                s := _p_.status

                ...
                } else if s == _Prunning {
                        // Preempt G if it's running for too long.
                        t := int64(_p_.schedtick)
                        if int64(pd.schedtick) != t {
                                pd.schedtick = uint32(t)
                                pd.schedwhen = now
                                continue
                        }
                        if pd.schedwhen+forcePreemptNS > now {
                                continue
                        }
                        preemptone(_p_)
                }
        }
        ...
}

Processor 在 Machine 上执行时间超过 10ms，Machine 会给调用 preemptone 给当前 Goroutine 加上标记：

// src/runtime/proc.go

func preemptone(_p_ *p) bool {
        ...
        gp.preempt = true

        // Every call in a go routine checks for stack overflow by
        // comparing the current stack pointer to gp->stackguard0.
        // Setting gp->stackguard0 to StackPreempt folds
        // preemption into the normal stack overflow check.
        gp.stackguard0 = stackPreempt
}

可以看到它并不是直接发信号给 Machine 让它立即释放，而是让 Goroutine 自己释放，那它什么时候会释放？

Golang 创建新的 Goroutine 时，都会分配有限的调用栈空间，按需进行拓展或者收缩。所以在执行下一个函数时，它会检查调用栈是否溢出。

➜  main go tool objdump -s "main.main" main
TEXT main.main(SB) /root/workspace/main/main.go
  main.go:7             0x450a60                64488b0c25f8ffffff      MOVQ FS:0xfffffff8, CX
  main.go:7             0x450a69                483b6110                CMPQ 0x10(CX), SP
  main.go:7             0x450a6d                7630                    JBE 0x450a9f    <= I'm here!!
  main.go:7             0x450a6f                4883ec18                SUBQ $0x18, SP
  main.go:7             0x450a73                48896c2410              MOVQ BP, 0x10(SP)
  main.go:7             0x450a78                488d6c2410              LEAQ 0x10(SP), BP
  main.go:8             0x450a7d                c7042400000000          MOVL $0x0, 0(SP)
  main.go:8             0x450a84                488d05e5190200          LEAQ 0x219e5(IP), AX
  main.go:8             0x450a8b                4889442408              MOVQ AX, 0x8(SP)
  main.go:8             0x450a90                e88bb4fdff              CALL runtime.newproc(SB)
  main.go:9             0x450a95                488b6c2410              MOVQ 0x10(SP), BP
  main.go:9             0x450a9a                4883c418                ADDQ $0x18, SP
  main.go:9             0x450a9e                c3                      RET
  main.go:7             0x450a9f                e88c7dffff              CALL runtime.morestack_noctxt(SB)
  main.go:7             0x450aa4                ebba                    JMP main.main(SB)

gp.stackguard0 = stackPreempt 设置会让检查失败，进入 runtime.morestack_noctxt 函数。它发现是因为 runtime.retake 造成，Machine 会保存当前 Goroutine 的执行上下文，重新进入 runtime.schedule。

你可能会问，如果这个 Goroutine 里面没有函数调用怎么办？请查看这个 issues/11462。

一般情况下，这样的函数不是死循环，就是很快就退出了，实际开发中这种的类型函数不会太多。

6. 关于线程数目

Processor 的数目决定 go binary 能同时处理多少 Goroutine 的能力，感觉 Machine 的数目应该不会太多。

➜  scheduler cat -n main.go
     1  package main
     2
     3  import (
     4          "log"
     5          "net/http"
     6          "syscall"
     7  )
     8
     9  func main() {
    10          http.HandleFunc("/sleep", func(w http.ResponseWriter, r *http.Request) {
    11                  tspec := syscall.NsecToTimespec(1000 * 1000 * 1000)
    12                  if err := syscall.Nanosleep(&tspec, &tspec); err != nil {
    13                          panic(err)
    14                  }
    15          })
    16
    17          http.HandleFunc("/echo", func(w http.ResponseWriter, r *http.Request) {
    18                  w.Write([]byte("hello"))
    19          })
    20
    21          log.Fatal(http.ListenAndServe(":8080", nil))
    22  }

Golang 提供了 GODEBUG 环境变量来观察当前 Goroutine/Processor/Machine 的状态。

➜  scheduler go build
➜  scheduler GODEBUG=schedtrace=2000 ./scheduler
SCHED 0ms: gomaxprocs=4 idleprocs=1 threads=6 spinningthreads=1 idlethreads=0 runqueue=0 [0 0 0 0]
SCHED 2008ms: gomaxprocs=4 idleprocs=4 threads=6 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 4016ms: gomaxprocs=4 idleprocs=4 threads=6 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]

GODEBUG=schedtrace=2000 会开启 schedtrace 模式，它会让 sysmon 中调用 schedtrace。

// src/runtime/proc.go

func schedtrace(detailed bool) {
        ...
        print("SCHED ", (now-starttime)/1e6, "ms: gomaxprocs=", gomaxprocs, " idleprocs=", sched.npidle, " threads=", sched.mcount, " spinningthreads=", sched.nmspinning, " idlethreads=", sched.nmidle, " runqueue=", sched.runqsize)
        ...
}

gomaxprocs:      当前 Processor 的数目
idleprocs:       空闲 Processor 的数目
threads:         共创建了多少个 Machine
spinningthreads: spinning 状态的 Machine
nmidle:          休眠状态的 Machine 数目
runqueue:        Global Runnable Queue 队列长度
[x, y, z..]:     每个 Processor 的 Local Runnable Queue 队列长度

下面我们会通过 wrk 对 sleep 和 echo 这两个 endpoint 进行压力测试，并关注 Machine 的数目变化。

➜  scheduler GODEBUG=schedtrace=2000 ./scheduler > echo_result 2>&1 &
[1] 6015
➜  scheduler wrk -t12 -c400 -d30s http://localhost:8080/echo
Running 30s test @ http://localhost:8080/echo
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    51.15ms  104.96ms   1.31s    89.35%
    Req/Sec     4.97k     4.48k   20.53k    74.84%
  1780311 requests in 30.08s, 205.44MB read
Requests/sec:  59178.76
Transfer/sec:      6.83MB
➜  scheduler head -n 20 echo_result
SCHED 0ms: gomaxprocs=4 idleprocs=1 threads=6 spinningthreads=2 idlethreads=0 runqueue=0 [0 0 0 0]
SCHED 2000ms: gomaxprocs=4 idleprocs=4 threads=6 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 4005ms: gomaxprocs=4 idleprocs=4 threads=6 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 6008ms: gomaxprocs=4 idleprocs=4 threads=6 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 8014ms: gomaxprocs=4 idleprocs=0 threads=12 spinningthreads=0 idlethreads=6 runqueue=195 [20 53 6 32]
SCHED 10018ms: gomaxprocs=4 idleprocs=0 threads=12 spinningthreads=0 idlethreads=6 runqueue=272 [65 16 5 37]
SCHED 12021ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=218 [97 5 52 7]
SCHED 14028ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=41 [2 1 25 3]
SCHED 16029ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=178 [10 31 45 38]
SCHED 18033ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=144 [15 92 47 0]
SCHED 20034ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=195 [1 7 4 41]
SCHED 22035ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=159 [88 14 41 5]
SCHED 24038ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=231 [47 19 53 41]
SCHED 26046ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=6 [1 0 1 10]
SCHED 28049ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=133 [61 13 97 53]
SCHED 30049ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=220 [13 49 29 28]
SCHED 32058ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=138 [40 93 63 50]
SCHED 34062ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=266 [51 9 38 31]
SCHED 36068ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=189 [1 3 46 14]
SCHED 38084ms: gomaxprocs=4 idleprocs=4 threads=13 spinningthreads=0 idlethreads=10 runqueue=0 [0 0 0 0]

测试 localhost:8080/echo 30s 之后，发现当前线程数目为 13。接下来再看看 localhost:8080/sleep 的情况。

➜  scheduler GODEBUG=schedtrace=1000 ./scheduler > sleep_result 2>&1 &
[1] 8284
➜  scheduler wrk -t12 -c400 -d30s http://localhost:8080/sleep
Running 30s test @ http://localhost:8080/sleep
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.01s    13.52ms   1.20s    86.57%
    Req/Sec    83.06     89.44   320.00     79.12%
  11370 requests in 30.10s, 1.26MB read
Requests/sec:    377.71
Transfer/sec:     42.79KB
➜  scheduler cat sleep_result
SCHED 0ms: gomaxprocs=4 idleprocs=1 threads=6 spinningthreads=2 idlethreads=0 runqueue=0 [0 0 0 0]
SCHED 1000ms: gomaxprocs=4 idleprocs=4 threads=6 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 2011ms: gomaxprocs=4 idleprocs=4 threads=6 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 3013ms: gomaxprocs=4 idleprocs=4 threads=282 spinningthreads=0 idlethreads=1 runqueue=0 [0 0 0 0]
SCHED 4020ms: gomaxprocs=4 idleprocs=4 threads=400 spinningthreads=0 idlethreads=1 runqueue=0 [0 0 0 0]
SCHED 5028ms: gomaxprocs=4 idleprocs=4 threads=401 spinningthreads=0 idlethreads=2 runqueue=0 [0 0 0 0]
SCHED 6037ms: gomaxprocs=4 idleprocs=4 threads=401 spinningthreads=0 idlethreads=2 runqueue=0 [0 0 0 0]
SCHED 7038ms: gomaxprocs=4 idleprocs=4 threads=402 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 8039ms: gomaxprocs=4 idleprocs=4 threads=402 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 9046ms: gomaxprocs=4 idleprocs=4 threads=402 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 10049ms: gomaxprocs=4 idleprocs=4 threads=402 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 11056ms: gomaxprocs=4 idleprocs=4 threads=402 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 12058ms: gomaxprocs=4 idleprocs=4 threads=402 spinningthreads=0 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 13058ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 14062ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 15064ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 16066ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 17068ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 18072ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 19083ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 20084ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 21086ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 22088ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 23096ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 24100ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 25100ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 26100ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 27103ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 28110ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
SCHED 33131ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=396 runqueue=0 [0 0 0 0]
SCHED 34137ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=400 runqueue=0 [0 0 0 0]
SCHED 35140ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=400 runqueue=0 [0 0 0 0]
SCHED 36150ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=400 runqueue=0 [0 0 0 0]
SCHED 37155ms: gomaxprocs=4 idleprocs=4 threads=403 spinningthreads=0 idlethreads=400 runqueue=0 [0 0 0 0]

压力测试完毕之后，创建的线程明显比 localhost:8080/echo 多不少。在压测过程中采用 gdb attach + thread apply all bt 查看这些线程都在做什么:

...
Thread 152 (Thread 0x7f4744fb1700 (LWP 27863)):
#0  syscall.Syscall () at /usr/local/go/src/syscall/asm_linux_amd64.s:27
#1  0x000000000047151f in syscall.Nanosleep (time=0xc42119ac90,
#2  0x000000000060f042 in main.main.func1 (w=..., r=0xc4218d8900)
#3  0x00000000005e8974 in net/http.HandlerFunc.ServeHTTP (f=
#4  0x00000000005ea020 in net/http.(*ServeMux).ServeHTTP (
#5  0x00000000005eafa4 in net/http.serverHandler.ServeHTTP (sh=..., rw=...,
#6  0x00000000005e7a5d in net/http.(*conn).serve (c=0xc420263360, ctx=...)
#7  0x0000000000458e31 in runtime.goexit ()
#8  0x000000c420263360 in ?? ()
#9  0x00000000007cf100 in crypto/elliptic.p224ZeroModP63 ()
#10 0x000000c421180ec0 in ?? ()
#11 0x0000000000000000 in ?? ()
Thread 151 (Thread 0x7f47457b2700 (LWP 27862)):
#0  syscall.Syscall () at /usr/local/go/src/syscall/asm_linux_amd64.s:27
#1  0x000000000047151f in syscall.Nanosleep (time=0xc4206bcc90,
#2  0x000000000060f042 in main.main.func1 (w=..., r=0xc4218cd300)
#3  0x00000000005e8974 in net/http.HandlerFunc.ServeHTTP (f=
#4  0x00000000005ea020 in net/http.(*ServeMux).ServeHTTP (
#5  0x00000000005eafa4 in net/http.serverHandler.ServeHTTP (sh=..., rw=...,
#6  0x00000000005e7a5d in net/http.(*conn).serve (c=0xc42048afa0, ctx=...)
#7  0x0000000000458e31 in runtime.goexit ()
#8  0x000000c42048afa0 in ?? ()
#9  0x00000000007cf100 in crypto/elliptic.p224ZeroModP63 ()
#10 0x000000c4204fd080 in ?? ()
#11 0x0000000000000000 in ?? ()
...

Red Hat 系列的机器可以直接使用 pstack 去 Dump 当前主进程内部的调用栈情况，可惜 Ubuntu 64 Bit 没有这样的包，只能自己写一个脚本去调用 gdb 来 Dump。

截取两个线程的调用栈信息，发现它们都在休眠状态，几乎都卡在 /usr/local/go/src/syscall/asm_linux_amd64.s 上。如果都阻塞了，那么它是怎么处理新来的请求？

// src/syscall/asm_linux_amd64.s

TEXT    ·Syscall(SB),NOSPLIT,$0-56
        CALL    runtime·entersyscall(SB)
        MOVQ    a1+8(FP), DI
        MOVQ    a2+16(FP), SI
        MOVQ    a3+24(FP), DX
        MOVQ    $0, R10
        MOVQ    $0, R8
        MOVQ    $0, R9
        MOVQ    trap+0(FP), AX	// syscall entry
        SYSCALL
        CMPQ    AX, $0xfffffffffffff001
        JLS     ok
        MOVQ    $-1, r1+32(FP)
        MOVQ    $0, r2+40(FP)
        NEGQ    AX
        MOVQ    AX, err+48(FP)
        CALL    runtime·exitsyscall(SB)
        RET
ok:
        MOVQ    AX, r1+32(FP)
        MOVQ    DX, r2+40(FP)
        MOVQ    $0, err+48(FP)
        CALL    runtime·exitsyscall(SB)
        RET

Syscall 会调用 runtime.entersyscall 会将当前 Processor 的状态设置为 _Psyscall。当进入系统调用时间过长时，retake 函数在这些 _Psyscall Processor 的状态改为 _Pidle，防止长时间地占用 Processor 导致整体不工作。

进入空闲状态的 Processor 可能会被 wakep 函数创建出来的新进程绑定上，然而新的 Goroutine 可能还会陷入长时间的系统调用，这一来就进入恶性循环，导致 go binary 创建出大量的线程。

当然，Golang 会限制这个线程数目。

// src/runtime/proc.go

func checkmcount() {
        // sched lock is held
        if sched.mcount > sched.maxmcount {
                print("runtime: program exceeds ", sched.maxmcount, "-thread limit\n")
                throw("thread exhaustion")
        }
}

当 Machine 从内核态回来之后，会进入 runtime.exitsyscall。如果执行时间很短，它会尝试地夺回之前的 Processor ；或者是尝试绑定空闲的 Processor，一旦绑定上了 Processor ，它便会继续运行当前的 Goroutine。如果都失败了，Machine 因为没有可绑定的 Processor 而将当前的 Goroutine 放回到全局队列中，将自己进入休眠状态，等待其他 Machine 来唤醒。

一般情况下，go binary 不会创建特别多的线程，但是上线的代码还是需要做一下压测，了解一下代码的实际情况。一旦真的创建大量的线程了，Golang 目前的版本是不会回收这些空闲的线程。不过好在 Go10/Go11 会改进这一缺点，详情请查看 issues/14592。

7. 总结

本文粗粒度地介绍了 Golang Goroutine Scheduler 的工作流程，并没有涉及到垃圾回收，Netpoll 以及 Channel Send/Receive 对调度的影响，希望能让读者有个大体的认识。

runtime.mstart 内部的细节很多，而且很多并发操作都建立在无锁的基础上，这样能减少锁对性能的影响，感兴趣的朋友可以根据上文提到的函数一步一步地查看，应该会有不少的收获。

8. Reference

Protobuf 3.0 编码

Wed, 15 Nov 2017 00:00:00 +0000

Protobuf 是 G 厂开源的序列化数据的方法，可用来通信或者存储数据。它采用 IDL 描述数据接口，使得不同语言编写的程序可以根据同一接口通信。不同编程语言也可以根据 IDL 的描述来生成对应数据结构，该数据结构用来编解码。为此，G 厂为主流开发语言都提供代码生成器（即 protoc ）。

为了更好地了解一些细节，本文将主要描述 Protobuf 3.0 的编码规则。 Protobuf 里面主要采用 Varint 和 Zig-Zag 的方式来对整型数字进行编码。在理解 Protobuf 之前，需要先了解这两种编码方式。

Protobuf 采用是 Little Endian 的方式编码。

1. Varints

int64, int32, uint64, uint32 都有固定的二进制位数。

如果将这些数字序列化成二进制流的时候，需要额外空间告知接收方数据的长度。对于采用 int64, uint64 这两种类型的数据而言，如果大部分时间都只是使用较小的数值，那么会极大地浪费传输带宽和存储空间。针对这两个问题，Protobuf 采用 Varints 的编码方式。

Varints 将源数据按照 7 bit 分组，每 7 bit 加 MSB (Most Significant Bit) 标识位来组成一个字节，其中 MSB 标识位用来判断是否存在后序分组。如果出现多组的情况，那么低有效位比特组优先。

64 有效位为 7 bit，不需要额外的字节，所以 MSB 比特位为 0。

64 = 0100 0000
  => 0100 0000

16657 有效位为 15 bit，需要分成三组字节，前两组字节为了提示还存在后续字节，所以前两组字节的 MSB 比特位为 1。

16657 = 0100 0001 0001 0001
  =>  001 0001 ++ 000 0010 ++ 000 0001 (reverse the groups of 7 bits)
  =>  1001 0001 1000 0010 0000 0001
  =>  0x91 0x82 0x01

由于负数的最高有效位为 1，int32 类型的负数固定需要 5 字节，而 int64 的负数需要 10 字节，基本上告别了空间效益。所以 Varints 在编码负数时，需要引入 Zig-Zag 编码解决压缩问题。

2. Zig-Zag

Signed Original	Encoded As
0	0
-1	1
1	2
-2	3
2	4
2147483647	4294967294
-2147483648	4294967295

Zig-Zag 编码可以将负数转化成正数，如上表所示。根据上述表格可以很快地得出结论，负数 n 编码后的值为 2 * abs(n) - 1，而正数，编码后为 2 * n。

实际上，Zig-Zag 会采用以下方式来进行编解码。为了简单起见，接下来将使用 int8 类型分析 Zig-Zag 编解码。

encode(n):
  int64 => (n << 1) ^ (n >> 63)
  int32 => (n << 1) ^ (n >> 31)
  int64 => (n << 1) ^ (n >> 15)
  int8  => (n << 1) ^ (n >> 7)

decode(n): 
  (n >>> 1) ^ - (n & 1)

NOTE: 
  <<, >> Arithmetic Shift
  >>>       Logical Shift

2.1 Encode

Zig-Zag 会将最高符号位算数位移到 LSB（Least significant bit）。

positive: (n >> 7) => 0x00
negative: (n >> 7) => 0xFF

任何数值与 0x00 异或都等到本身，而与 0xFF 异或会现成按位取反。根据补码互补的原理，一个数 A 与 0xFF 异或就变成 -A - 1。

A ^ 0xFF = ~A = -A - 1

因此，负数经过运算之后变成 - 2 * n - 1。而正数经过运算只是简单扩大两倍而已，将会 2 * n。

-2 => 3

  1111 1100 (1111 1110 << 1)
^ 1111 1111 (1111 1110 >> 7)
-----------------
  0000 0011 (-2 << 1) ^ (-2 >> 7)

2.2 Decode

Zig-Zag 编码的时候将最高符号位移位到了 LSB，解码的时候需要还原到 MSB。

positive: - (n & 1) = 0  => 0x00
negative: - (n & 1) = -1 => 0xFF

n >>> 1 逻辑右移的过程相当于做了除以 2 的操作，所有奇数的逻辑右移都可以得到 n / 2 = (n - 1)/2，根据解码的表达式可以得到以下推断。

n & 1 == 0:
  (n >>> 1) ^ -(n & 1) = (n >>> 1) = n / 2

n & 1 == 1:
  (n >>> 1) ^ -(n & 1) = ~(n >>> 1) = - (n >>> 1) - 1 = - (n + 1) / 2

255 解码之后的结果为 -128。如果解码过程是通过先加后除的方式，将会出现溢出错误。

255 => -128

  0111 1111 (1111 1111 >>> 1)
^ 1111 1111 (-(1111 1111 & 1))
-----------------
  1000 0000 (255 >>> 1) ^ -(255 & 1)

Protobuf 在编码负数的时候，它提供了 Zig-Zag 编码的可能，可在此基础上在使用 Varints 来达到压缩效果。

3. Message

message Simple {
  //
  //     _ declared type
  //    /      _ field name
  //   /      /     _ field number, alias tag
  //  /      /     /
  int64 o_int64 = 16;
}

Protobuf Message 是一系列的 Key-Value 二进制数据流。在编码过程中，仅仅使用 field number 和 wire type 为 Key，而 declared type 和 field name 会辅助解码来判断数据的具体类型，其中 wire type 有以下几种类型。

Wire Type	Meaning	Used For
0	Varint	int32, int64, uint32, uint64, sint32, sint64, bool, enum
1	64-bit	fixed64, sfixed64, double
2	Length-delimited	string, bytes, embedded messages, packed repeated fields
3	Start Group	groups (deprecated)
4	End Group	groups (deprecated)
5	32-bit	fixed32, sfixed64, float

每一个 Key 都是 (field number << 3 | wire type) 的 Varint 编码值。

现在按照 Simple 的约定发送来以下数据。接下来，我们将作为人工解码器来分析这份数据。

80 01 96 01

首先 Protobuf Message 编码之后是一系列的 Key-Value，因此首字节属于 Key 的一部分。Key 首字节 80 的 MSB 标志位为 1，说明 Key 除了 80 外还有后序字节。根据上文 Varints 的介绍，可以得到 Key 中 field number(16) 和 wire type(0)。

80 01

1000 0000 0000 0001
   => 000 0000 ++ 000 0001  (drop the msb)
   => 1000 0000             (reverse the groups of 7 bits)
   => (0001 0000 << 3) | 0

按照同样方式，Value 数据为 96 01。经过 Varints 解码后为 150，所以 80 01 96 01 代表着 Simple.o_int64 = 150。

96 01

1001 0110 0000 0001
  => 001 0110 ++ 000 0001    (drop the msb)
  => 1001 0110               (reverse the groups of 7 bits)
  => 128 + 16 + 4 + 2 = 150

4. Wire Type

4.1 Varint - sint32/sint64

对于负数而言，前序比特 1 不能带来压缩上效益，所以 Protobuf 提供 sint32，sint64 类型来使用 Zig-Zag 提高压缩率。

4.2 32-bit / 64-bit

这两部分 wire type 会使用固定长度去传输数据，其中 64-bit 采用 8 字节传输，而 32-bit 采用 4 字节传输。

4.3 Length-delimited

Length-delimited 会引入 payload size 来辅助说明后序字节数，其中 payload size 的编码采用 Varints 。

strings/bytes

message SimpleString {
  string o_string = 1;
}

将 o_string 设置成 Hello, world!，会得到以下数据。

0A 0D 48 65 6C 6C 6F 2C 20 77 6F 72 6C 64 21

Key 0A 可以推断出 field number(1) 和 wire type(2)。payload size(0D) 解码之后为 13 ，后序 13 个字节将代表 o_string。

embedded messages

message SimpleEmbedded {
  Simple o_embedded = 1; 
}

将 o_embedded.o_int64 设置成 150，会得到以下数据。

0A 04 80 01 96 01

Key 0A 可以推断出 field number(1) 和 wire type(2)。payload size(04) 解码之后为 4 ，后序 4 个字节将代表 o_embedded。整个过程基本和 SimpleString 一致，只不过 o_embedded 还需要进一步的解码。

packed repeated fields

Protobuf 3.0 对于 repeated field 默认都采用了 packed 的形式。不过在介绍 packed 特性前，有必要说明一下 unpacked 的编码结构。

message SimpleInt64 {
  int64 o_int64 = 1;
}

message SimpleUnpacked {
  repeated int64 o_ids = 1 [packed = false];
}

message SimplePacked {
  repeated int64 o_ids = 1;
}

将 SimpleUnpacked.o_ids 设置成 1,2 数组，会得到以下数据。

08 01 08 02

08 // field number = 1, wire type = 0
01 // value = 1 
08 // field number = 1, wire type = 0
02 // value = 2

Protobuf 编码 unpacked repeated fields 时，并不会将 repeated fields 看成是一个整体，而是单独编码每一个元素。所以在解码 unpacked repeated fileds 时，需要将相同 field number 的数据合并到一起。

从另外一个角度看，Protobuf 允许将相同 Key 的数据合并到一起。08 01 08 02 数据可以看成是 SimpleInt64.o_int64 = 1 和 SimpleInt64.o_int64 = 2 编码合并的结果。

让我们来看看 packed repeated fields 编码结果。同样将 SimplePacked.o_ids 设置成 1,2 数组，却得到不同的数据，因为 Protobuf 编码时将 o_ids 看成是一个整体。

0A 02 01 02

0A // field number = 1, wire type = 2
02 // payload size = 2
01 // first elem = 1
02 // second elem = 2

Protobuf 3.0 packed 的行为仅仅支持基础数据类型，即 Varint/64-bit/32-bit 三种 wire type。

packed 和 unpacked 编码面对长度为 0 的数据时，它并不会输出任何二进制数据。

个人认为基础数据类型所占用字节数少，整体字节数相对可控，引入 payload size 能带来压缩效益。一旦使用 embedded message 之后，每一个元素的大小将不可控，可能只有少量元素，但是整体字节数将会很大，payload size 需要大量的字节表示。面对这种场景，unpacked repeated fields 单独编码的方式会带来压缩效益，即使包含了重复的 Key 信息。

5. Start Group/End Group

由于 Protobuf 放弃使用 Start Group 和 End Group，在此也不再介绍。

6. Reference

Protocol Buffers Encoding

Go Interface & Duck Typing

Mon, 05 Jun 2017 00:00:00 +0000

Go 不需要像 Java 那样显式地使用 implement 说明某一数据类型实现了 interface，只要某一数据类型实现了 interface 所定义的方法名签，那么就称该数据类型实现了 interface。interface 的语言特性可以容易地做到接口定义和具体实现解耦分离，并将注意力转移到如何使用 interface ，而不是方法的具体实现，我们也称这种程序设计为 Duck Typing。文本将描述 Go 是如何通过 interface 来实现 Duck Typing。

本文提供的源代码都是基于 go1.7rc6 版本。

1. Duck Typing

了解实现原理之前，我们可以简单过一下 Go 的 Duck Typing 示例。

package main

type Ducker interface { Quack() }

type Duck struct {}
func (_ Duck) Quack() { println("Quaaaaaack!") }

type Person struct {} 
func (_ Person) Quack() { println("Aha?!") }

func inTheForest(d Ducker) { d.Quack() }

func main() {
	inTheForest(Duck{})
	inTheForest(Person{})
}

// result:
// Quaaaaaack!
// Aha?!

在示例中，inTheForest 函数使用了 Ducker 的 Quack() 方法，而 Quack() 方法的具体实现由实参所决定。根据 Go interface 的定义，Duck 和 Person 两种数据类型都有 Quack() 方法，说明这两种数据类型都实现了 Ducker 。当实参分别为这两种类型的数据时，inTheForest 函数表现出『多态』。

在这没有继承关系的情况下，Go 可以通过 interface 的 Duck Typing 特性来实现『多态』。作为一个静态语言，Go 是如何实现 Duck Typing 这一特性？

2. interface data structure

interface 是 Go 数据类型系统中的一员。在分析运行机制之前，有必要先了解 interface 的数据结构。

2.1 empty interface

// src/runtime/runtime2.go
type eface struct {
    _type *_type
    data  unsafe.Pointer
}

当一个 interface 没有定义方法签名时，那么我们称之为 empty interface。它由 _type 和 data 组成，其中 data 表示 interface 具体实现的数据，而 _type 是 data 对应数据的类型元数据。因为没有定义方法签名，所以任何类型都『实现』empty interface。换句话来说，empty interface 可以接纳任何类型的数据。

package main

func main() {
    i := 1
    var eface interface{} = i
    
    println(eface)
}

// gdb info
// (gdb) i locals
// i = 1
// eface = {
//   _type = 0x55ec0 <type.*+36000>,
//   data = 0xc420045f18
// }
// (gdb) x/x eface.data
// 0xc420045f18:   0x00000001
// (gdb) x/x &i
// 0xc420045f10:   0x00000001

在使用 gdb 来查看 eface 数据结构的过程中，我们会发现比较特别的一点：eface.data 和 i 的地址不同。一般情况下，将一个数据赋值给 interface 时，程序会为数据生成一份副本，并将副本的地址赋给 data 。

// src/cmd/compile/internal/gc/subr.go
// Can this type be stored directly in an interface word?
// Yes, if the representation is a single pointer.
func isdirectiface(t *Type) bool {
    switch t.Etype {
    case TPTR32,
        TPTR64,
        TCHAN,
        TMAP,
        TFUNC,
        TUNSAFEPTR:
        return true

    case TARRAY:
        // Array of 1 direct iface type can be direct.
        return t.NumElem() == 1 && isdirectiface(t.Elem())

    case TSTRUCT:
        // Struct with 1 field of direct iface type can be direct.
        return t.NumFields() == 1 && isdirectiface(t.Field(0).Type)
    }

    return false
}

当一个数据的类型符合 isdirectiface 的判定时，那么程序不会生成副本，而是直接将实际地址赋给 data 。由于这部分内存分配优化和 reflect 实现有关，在此就不做展开描述了。

reflect 要想在运行时解析数据的方法和属性，它就需要知道数据以及类型元数据。而 empty interface 正好能满足这一需求，这也正是 reflect 的核心方法 ValueOf 和 TypeOf 的形参是 empty interface 的原因。

在 Duck Typing 的使用上，empty interface 使用频率比较高的场景是 Type Switch, Type Assertion，接下来会介绍这些使用场景。

2.2 non-empty interface

相对于 empty interface 而言，有方法签名的 interface 的数据结构要复杂一些。

// src/runtime/runtime2.go
type iface struct {
    tab  *itab
    data unsafe.Pointer
}

type itab struct {
    inter  *interfacetype
    _type  *_type
    link   *itab
    bad    int32
    unused int32
    fun    [1]uintptr // variable sized
}

iface 包含两个字段 tab 和 data。和 empty interface 一样，data 表示具体实现的数据。tab 不再是简单的 _type，不仅维护了（interfacetype，_type）匹配的信息，还维护了具体方法实现的列表入口 fun。

其中 interfacetype 是相应 interface 类型的元数据。而 fun 字段是一个变长数组的 header ，它代表着具体方法数组的头指针，程序通过fun去定位具体某一方法实现。

来看看下面这一段程序。

package main

type Ducker interface {
        Quack()
        Feathers()
}

type Duck struct{ x int }

func (_ Duck) Quack() { println("Quaaaaaack!") }

func (_ Duck) Feathers() { println("The duck has white and gray feathers.") }

func inTheForest(d Ducker) {
        d.Quack()
        d.Feathers()
}

func main() {
        inTheForest(Duck{x: 1})
}

// gdb info at func inTheForest
(gdb) p d
$2 = {
  tab = 0x97100 <Duck,main.Ducker>,
  data = 0xc42000a118
}
(gdb) x/2xg d.tab.fun
0x97120 <go.itab.main.Duck,main.Ducker+32>:     0x00000000000022f0      0x0000000000002230
(gdb) i symbol 0x00000000000022f0
main.(*Duck).Feathers in section .text
(gdb) i symbol 0x0000000000002230
main.(*Duck).Quack in section .text

在 inTheForest 函数里，d.tab.fun 数组包含了 Duck 的 Quack 以及 Feathers 的方法地址，因此在 d.Quack() 和 d.Feathers() 分别使用了 Duck 的 Quack 和 Feathers 方法的具体实现。假如这个时候，传入的不是 Duck ，而是其他实现了 Ducker 的数据类型，那么 d.tab.fun 将会包含相应类型的具体方法实现。

d.tab.fun 不会包含 interface 定义以外的方法地址。

不难发现，itab.fun 包含了具体方法的实现，程序在运行时通过 itab.fun 来决议具体方法的调用，这也是实现 Duck Typing 的核心逻辑。那么问题来了，itab 是什么时候生成的？

3. itab

当数据类型 Duck 实现了 Ducker 中的所有方法时，编译器才会生成 itab，并将 Duck 对 Ducker 的具体实现绑定到 itab.fun 上，否则编译不通过。itab.fun 很像 C++ 中的虚函数表。而 Go 没有继承关系，一个 interface 就可能会对应 N 种可能的具体实现，这种 M:N 的情况太多，没有必要去为所有可能的结果生成 itab。因此，编译器只会生成部分 itab，剩下的将会在运行时生成。

C++ 通过继承关系，在编译期间就生成类的虚函数表。在运行状态下，通过指针来查看虚函数表来定位具体方法实现。

当一个数据类型实现 interface 中所声明的所有方法签名，那么 iface 就可以携带该数据类型对 interface 的具体实现，否则将会 panic 。这部分判定需要 _type 和 interfacetype 元数据，而这部分数据在编译器已经为运行时准备好了，那么判定和生成 itab 就只要照搬编译器里那一套逻辑即可。

// src/runtime/iface.go
var (
    ifaceLock mutex // lock for accessing hash
    hash      [hashSize]*itab
)

func itabhash(inter *interfacetype, typ *_type) uint32 {...}
func getitab(inter *interfacetype, typ *_type, canfail bool) *itab {...}
func additab(m *itab, locked, canfail bool) {...}

// src/runtime/runtime2.go
type itab struct {
    inter  *interfacetype
    _type  *_type
    link   *itab
    bad    int32
    unused int32
    fun    [1]uintptr // variable sized
}

为了保证运行效率，程序会在运行时会维护全局的 itab hash 表，getitab 会在全局 hash 表中查找相应的 itab。当 getitab 发现没有相应的 itab 时，它会调用 additab 来添加新的 itab。在插入新的 itab 之前，additab 会验证 _type 对应的类型是否都实现了 interfacetype 声明的方法集合。

运行时通过 itabhash 负责生成 hash 值，并使用单链表来解决冲突问题，其中 itab.link 可用来实现链表。

那么问题又来了，_type 有 N 个方法，interfacetype 有 M 个方法签名，验证匹配的最坏可能性就是需要 N * M 次遍历。除此之外，additab 在写之前需要加锁，这两方面都会影响性能。

3.1 additab 的效率问题

为了减少验证的时间，编译期间会对方法名进行排序，这样最坏的可能也就需要 N + M 次遍历即可。

细心的朋友可能会发现，在上一个例子中 d.tab.fun 中的方法是按照字符串大小排序的。

// src/runtime/iface.go
func additab(m *itab, locked, canfail bool) {
    inter := m.inter
    typ := m._type
    x := typ.uncommon()

    // both inter and typ have method sorted by name,
    // and interface names are unique,
    // so can iterate over both in lock step;
    // the loop is O(ni+nt) not O(ni*nt).
    ...
}

3.2 锁的效率问题

关于锁的问题，在实现 getitab 的时候，引入了两轮查询的策略。因为 itab 数据比较稳定，引入两轮查询可以减少锁带来的影响。

// src/runtime/iface.go
func getitab(inter *interfacetype, typ *_type, canfail bool) *itab {
    ....
    // look twice - once without lock, once with.
    // common case will be no lock contention.
    var m *itab
    var locked int
    for locked = 0; locked < 2; locked++ {
        if locked != 0 {
            lock(&ifaceLock)
        }
        ...
     }
     ...
}

itab 的生成和查询或多或少带有运行时的开销。然而 itab 不仅提供了静态语言的类型检查，还提供了动态语言的灵活特性。只要不滥用 interface，itab 还是可以提供不错的编程体验。

4. Type Switch & Type Assertion

开发者会使用 interface 的 Type Switch 和 Type Assertion 来进行『类型转化』。

package main

type Ducker interface { Feathers() }

type Personer interface { Feathers() }

type Duck struct{}

func (_ Duck) Feathers() { /* do nothing */ }

func example(e interface{}) {
	if _, ok := e.(Personer); ok {
		println("I'm Personer")
	}
	
	if _, ok := e.(Ducker); ok {
		println("I'm Ducker")
	}
}

func main() {
     var d Ducker = Duck{}
     example(d)
}

// result:
// I'm Personer
// I'm Ducker

根据之前对 itab 的分析，其实 e.(Personer) 和 e.(Ducker) 这两个断言做的就是切换 itab.inter 和 itab.fun ，并不是动态语言里的『类型转化』。那么断言的函数入口在哪？

// go tool objdump -s 'main.example' ./main
        main.go:15      0x2050  65488b0c25a0080000      GS MOVQ GS:0x8a0, CX
        main.go:15      0x2059  483b6110                CMPQ 0x10(CX), SP
        main.go:15      0x205d  0f86eb000000            JBE 0x214e
        main.go:15      0x2063  4883ec38                SUBQ $0x38, SP
        main.go:15      0x2067  48896c2430              MOVQ BP, 0x30(SP)
        main.go:15      0x206c  488d6c2430              LEAQ 0x30(SP), BP
        main.go:16      0x2071  488d05c8840500          LEAQ 0x584c8(IP), AX
        main.go:16      0x2078  48890424                MOVQ AX, 0(SP)
        main.go:16      0x207c  488b442448              MOVQ 0x48(SP), AX
        main.go:16      0x2081  488b4c2440              MOVQ 0x40(SP), CX
        main.go:16      0x2086  48894c2408              MOVQ CX, 0x8(SP)
        main.go:16      0x208b  4889442410              MOVQ AX, 0x10(SP)
        main.go:16      0x2090  48c744241800000000      MOVQ $0x0, 0x18(SP)
     => main.go:16      0x2099  e892840000              CALL runtime.assertE2I2(SB)
        main.go:16      0x209e  0fb6442420              MOVZX 0x20(SP), AX
        main.go:16      0x20a3  8844242f                MOVB AL, 0x2f(SP)

通过 objdump 发现一个很特别的方法：runtime.assertE2I2。assertE2I2 是一个断言函数，它负责判断一个 empty interface 里的数据能否转化成一个 non-empty interface，名字最后那个 2 代表着有两个返回值：

第一参数是转化后的结果
第二参数是断言结果

接下来看看 assertE2I2 的源码。

// src/runtime/iface.go
func assertE2I2(inter *interfacetype, e eface, r *iface) bool {
    if testingAssertE2I2GC {
        GC()
    }
    t := e._type
    if t == nil {
        if r != nil {
            *r = iface{}
        }
        return false
    }
    tab := getitab(inter, t, true)
    if tab == nil {
        if r != nil {
            *r = iface{}
        }
        return false
    }
    if r != nil {
        r.tab = tab
        r.data = e.data
    }
    return true
}

该函数会拿出 empty interface 中的 _type 和 interfacetype 在 getitab 中做查询和匹配验证。如果验证通过，r 会携带转化后的结果，并返回 true。否则返回 false。

src/runtime/iface.go 中还有很多类似 assertE2I2 的函数，在这里就不一一阐述了。

// T: 具体的数据类型_type
// E: empty interface
// I:  non-empty interface

// src/runtime/iface.go
func assertE2I(inter *interfacetype, e eface, r *iface) {...}
func assertI2I2(inter *interfacetype, i iface, r *iface) bool {..}
func assertI2E(inter *interfacetype, i iface, r *eface) {...}
func assertI2E2(inter *interfacetype, i iface, r *eface) bool {...}
func assertE2T2(t *_type, e eface, r unsafe.Pointer) bool {..}
func assertE2T(t *_type, e eface, r unsafe.Pointer) {..}
func assertI2T2(t *_type, i iface, r unsafe.Pointer) bool {...}
func assertI2T(t *_type, i iface, r unsafe.Pointer) {...}

func convI2I(inter *interfacetype, i iface) (r iface) {...}
func convI2E(i iface) (r eface) {...}

5. 最后

interface 的 Duck Typing 可以用来实现『多态』、代码的模块化。但是这毕竟有运行时的开销，interface 的滥用和声明大量的方法签名还是会影响到性能。

6. Reference

让你的 shell 脚本变得可控

Mon, 20 Mar 2017 00:00:00 -0400

刚开始接触 shell 脚本的时候，最痛苦的地方在于出了问题，却不容易定位问题。

shell 脚本遇到错误，“大部分” 情况下都会继续执行剩下的命令，最后返回 Zero Exit Code 并不代表着结果正确。

这让人很难发现问题，它不像其他脚本语言，遇到 语法错误 和 typo 等错误时便会立即退出。

如果想要写出容易维护、容易 debug 的 shell 脚本，我们就需要让 shell 脚本变得可控。

set -e

默认情况下，shell 脚本遇到错误并不会立即退出，它还是会继续执行剩下的命令。

[root@localhost ~]# cat example
#!/usr/bin/env bash
# set -e

sayhi # this command is not available.
echo "sayhi"
[root@localhost ~]# ./example
./example: line 4: sayhi: command not found
sayhi

我们知道 Linux/Unix 用户等于系统的时候，内核会加载 .bashrc 或者 .bash_profile 里的配置。

不同 shell 版本会使用不同的 rc/profile 文件，比如 zsh 版本的 rc 文件名是 .zshrc。

简单设想下，假如 shell 脚本遇到错误就退出，那么只要这些文件里有 typo 等错误，该用户就永远登陆不了系统。

在此，并没有考究默认行为的设计缘由，只是想表达 shell 脚本默认行为会让脚本变得不可控。

set -e 能会让 shell 脚本遇到 Non-Zero Exit Code 时，会立即停止执行。

[root@localhost ~]# cat example
#!/usr/bin/env bash
set -e

sayhi # this command is not available.
echo "sayhi"
[root@localhost ~]# ./example
./example: line 4: sayhi: command not found

set -u

初始化后再使用变量，这是好的编程习惯。

但在默认情况下，shell 脚本使用未初始化的变量并不会报错。

[root@localhost ~]# cat example
#!/usr/bin/env bash
# set -u

echo "Hi, ${1}"
[root@localhost ~]# ./example
Hi,
[root@localhost ~]# echo $?
0

若脚本设置 set -u ，一旦使用没有初始化的变量或者 positional parameter 时，脚本将立即返回 1 Exit Code。

[root@localhost ~]# cat example
#!/usr/bin/env bash
set -u

echo "Hi, ${1}"
[root@localhost ~]# ./example
./example: line 4: 1: unbound variable
[root@localhost ~]# echo $?
1

需要说明的是，对于预定义的 $@, $* 等这些变量，是可以正常使用。

为了避免使用未初始化的变量，常使用 ${VAR:-DEFAULT} 来设置默认值。

#!/usr/bin/env bash
set -u

# ${VAR:-DEFAULT} evals to DEFAULT if VAR undefined.
foo=${nonexisting:-ping}

echo "${foo}" # => ping

bar="pong"

foo=${bar:-ping}

echo "${foo}" # => pong

# DEFAULT can be empty
empty=${nonexisting:-}

echo "${empty}" # => ''

set -o pipefail

在默认情况下，pipeline 会采用最后一个命令的 Exit Code 作为最终返回的 Exit Code。

[root@localhost ~]# cat example
#!/usr/bin/env bash
# set -o pipefail

grep string /non-existing-file | sort
[root@localhost ~]# ./example
grep: /non-existing-file: No such file or directory
[root@localhost ~]# echo $?
0

明明报错了，为什么还会返回 Zero Exit Code?

grep 一个并不存在的文件会返回 2 Exit Code。grep 不仅会输出错误信息到 STDERR 上，还会输出空的字符串到 STDOUT。对于 sort 命令而言，空字符串是合法的输入，所以最后命令返回 Zero Exit Code。

这样错误信息并不能很好地帮助我们改善脚本，返回的 Exit Code 应该要尽可能地反映错误现场。

和前面两个设置一样，set -o pipefail 会让 shell 脚本在 pipeline 过程遇到错误便立即返回相应错误的 Exit Code。

[root@localhost ~]# cat example
#!/usr/bin/env bash
set -o pipefail

grep string /non-existing-file | sort
[root@localhost ~]# ./example
grep: /non-existing-file: No such file or directory
[root@localhost ~]# echo $?
2

non-zero exit code is expected

这三个配置太过于苛刻，某些情况下还需要放宽这些限制：当程序可以接受 non-zero exit code 时。

这里有两种常用的方式去放宽限制：

set +

这里有一个脚本是用来产生长度为 64 的随机字符串：

root@localhost ~]# cat example
#!/usr/bin/env bash
set -euo pipefail

str=$(cat /dev/urandom | tr -dc '0-9A-Za-z' | head -c 64)

echo "${str}"

[root@localhost ~]# ./example
[root@localhost ~]# echo $?
141

该脚本有一个问题，就是 head 命令在获取到第 64 个字节之后，会关闭 STDIN，但是 pipe 还在不断地输出，导致内核不得不抛出 SIGPIPE 来终止命令。

因为设置 set -o pipefail 了，整个脚本因为 SIGPIPE 会退出。

假设该脚本剩下命令还很多，不能整体去掉 pipefail ，那么我们就局部放弃这个限制好了。

[root@localhost ~]# cat example
#!/usr/bin/env bash
# exit immediately if non-zero exit code/unset variable/pipe error
set -euo pipefail

# loosen up
set +o pipefail
str=$(cat /dev/urandom | tr -dc '0-9A-Za-z' | head -c 64)
set -o pipefail

echo "${str}"

[root@localhost ~]# ./example
pvScFHDZrdjlI091rQbruyEPM9e6iTN59IyzaKcCJwiCxYmiSNRmkFOfp0YuXi1C
[root@localhost ~]# echo $?
0

同理，只要设置上 set +e 或者 set +u 时，就会放宽相应的限制。

记得 有借有还，再借不难 就好了。

短路运算

现在有一个脚本，该脚本用来统计文件 file 中有多少行是包含了 string 这个字符串。

root@localhost ~]# cat example
#!/usr/bin/env bash
set -euo pipefail

count=$(grep -c string ./file)

echo "${count}"

[root@localhost ~]# ./example
[root@localhost ~]# echo $?
1
[root@localhost ~]# cat ./file
example

因为文件 file 中并不包含 string 这一字符串，所以 grep 返回 1 Exit Code。

假设遇到没有匹配上的文件，该脚本应该显示零，而不是错误。

$(cmd || true) 短路运算会让该命令永远都正常执行。

[root@localhost ~]# cat example
#!/usr/bin/env bash
set -euo pipefail

count=$(grep -c string ./file || true)

echo "${count}"

[root@localhost ~]# ./example
0
[root@localhost ~]# echo $?
0

思考

shell 脚本能帮助我们轻松地完成自动化的任务，这是它的优势。

但是劣势也比较明显，就是 shell 脚本的返回值。我们来看看下面的一个例子。

相对于 if/else, 短路运算可以让代码变得简洁。

但是一旦最终的判断结果为否，那么该短路运算将会返回 Non-Zero Exit Code。

假如有一个脚本的最后一条命令是短路运算。

[root@localhost ~]# cat ./echo_filename
#!/usr/bin/env bash
set -euo pipefail

file=${1:-}

[[ -f "${file}" ]] && echo "File: ${file}"
[root@localhost ~]# ./echo_filename
[root@localhost ~]# echo $?
1

如果没有传参数，那么短路运算将会返回 1 Exit Code，这个结果也将作为整个脚本的返回结果。

需要说明的是，虽然短路运算返回的 Non-Zero Exit Code，但 set -e 不会因为它而退出。

然后我们再看看使用 if/else 的结果。

[root@localhost ~]# cat echo_filename
#!/usr/bin/env bash
set -euo pipefail

file=${1:-}

if [[ -f "${file}" ]]; then
    echo "File: ${file}"
fi
[root@localhost ~]# ./echo_filename
[root@localhost ~]# echo $?
0

从逻辑上来分析，即使不传参数，呈现的应该是空字符串，并返回 Zero Exit Code。

if/else 语句相对于短路运算要合理。

我们别小看这一区别，如果这里有脚本调用 echo_filename，那么使用短路运算将会导致调用该脚本的脚本停止工作。

归根结底，是因为 shell 脚本并不像其他语言那样支持返回多种数据类型，它只能返回数字的 Exit Code。

这就代表着脚本的程序设计必须要考虑返回正确的 Exit Code，这样 set -euo pipefail 才能让脚本变得更加可控。

关于 set 更多的内容，请前往 Link 。

shebang - #!

Sun, 19 Mar 2017 00:00:00 -0400

写脚本的时候通常会在脚本的开头加上 shebang, 系统会将这段内容作为解释器指令，比如 bash shell 脚本。

$> cat example
#!/usr/bin/bash
echo "HaHa"

$> chmod +x ./example

$> ./example
HaHa

只要为脚本添加了可执行的属性，那么内核在执行脚本的时候，会调用 shebang 描述的解释器来执行脚本。 ./exmaple 其实等价于 /usr/bin/bash ./example。shebang 描述的解释器需要写其绝对路径或者相对路径，因为内核并不会在用户设置的 PATH 里找解释器。关于 shebang，讨论最多的应该是 兼容性 和 版本控制 问题。

兼容性

Linux 和 Unix 在存放解释器的具体路径不太一致，比如 Linux 会放到 /usr/bin/ 中，而 openBSD 会放到 /usr/local/bin/ 中。不同包管理器在安装解释器的时候，存放的位置也不尽相同。当你在 Mac 上写了 shell 脚本，测试并提交到代码库。结果等到部署的那一天，执行脚本的时候发现找不到解释器了。为了解决这个问题，可以通过 env 来解决，因为它在 Linux 和 Unix 存放的位置相同。

$> cat exmaple
#!/usr/bin/env bash
echo "HaHa"

env 会在用户设置的 PATH 中查找解释器第一次出现的具体路径。虽然办法比较 tricky，但是这种方式能解决脚本解释器的兼容性问题。

版本控制

env 会在用户配置的 PATH 中查找解释器第一次出现的具体路径。这个机制就说明这存在两个问题：

不同用户配置的 PATH 内容不同，导致找到的解释器版本会出现不一致
很难通过 env 的方式来做到版本控制

所以有些人坚持不用 /usr/bin/env cmd 这种方式。

思考

从部署的角度看，线上机器的环境都是一致的，而且都是通过自动化脚本去安装各种依赖。版本控制较细，这种情况下，不太建议采用 env 这种方式。如果从开发者的角度看，还是希望脚本能做到兼容，毕竟开发者的环境千差万别，env 基本上能解决这一大痛点。

不用 env 这种方式，就得确保测试环境和线上机器是一致的，通常 Docker 和虚拟机都能解决这样的问题。

Netfilter 初探

Fri, 17 Mar 2017 00:00:00 -0400

Linux 内核在 2.4.x 版本中正式引入 Netfilter 模块，该模块负责网络数据包过滤和 Network Address Translation。 Netfilter 代表着一系列的 Hook ，被内核嵌入到 TCP/IP 协议栈中，数据包在穿梭协议栈时，Hook 会检查数据包，从而达到访问控制的作用。

规则链

Netfilter 模块默认定义了五种类型的 Hook：

PREROUTING
INPUT
FORWARD
OUTPUT
POSTROUTING

在 Netfilter 里，Hook 也称为 Chain，规则链

我们可以从数据包的来源和走向入手来进行分析这条五条规则链的设计。首先，数据包按照来源可以分成 Incoming 和 Outgoing 这两种类型。 Incoming 数据包是指其他网卡发来的数据包。这类数据包可能直接奔向用户态的程序，也有可能被内核转发到其他机器或者其他网卡上，这需要内核做路由判定。

而 Outgoing 数据包是用户态程序准备要发送的数据包。数据包到达内核之后，内核会为它选择合适的网卡和端口，在此之后便会一层层地穿过协议栈，内核在此过程之中会做出路由判定。

一般情况下，客户端所使用的高端口号。在 Linux 下，我们可以通过 cat /proc/sys/net/ipv4/ip_local_port_range 查看系统会随机使用的端口号范围。

需要注意的是，如果这是内网和外网之间的通信，内核会使用到 NAT 技术来对地址进行转化。对于 Incoming 数据包而言，内核路由前需要对数据包进行 Destination NAT 转化。同理，数据包在路由之后也需要做 Source NAT 转化。

根据上面的分析，可以得到以下结论：

Incoming 数据包的目的地就在本地：PREROUTING -> INPUT
Incoming 数据包需要转发：PREROUTING -> FORWARD -> POSTROUTING
Outgoing 数据包：OUTPUT -> POSTROUTING

不同走向的数据包都必定会通过以上五个环节中的部分环节，只要系统管理员在五个环节中设置关卡，就可以做到系统的访问控制。

功能表

为了更好地管理访问控制规则，Netfilter 制定 功能表 来定义和区分不同功能的规则。

Netfilter 一共有五种功能表：

raw: 当内核启动 ip_conntrack 模块以后，所有信息都会被追踪，raw 却是用来设置不追踪某些数据包
mangle: 用来设置或者修改数据包的 IP 头信息
nat: 用来设置主机的 NAT 规则，用来修改数据包的源地址和目的地址
filter: 通常情况下，用来制定接收、转发、丢弃和拒绝数据包的规则
security: 安全相关

由于 filter 和 nat 基本能满足大部分的访问控制需求，加上篇幅的原因，接下来只会介绍 filter 和 nat 这两张功能表。

不同的功能表有内置的规则链。

filter: INPUT／OUTPUT ／FORWARD
nat: PREROUTING ／INPUT／OUTPUT／POSTROUTING

Linux 内核 2.6.34 开始给 nat 功能表引入了 INPUT 规则链，具体详情请查看 Commit。

不同来源的数据包的走向不同，触发的规则链也不同。

Incoming 数据包

+----------------------+                               +-------------------------------------+
| chain: PREROUTING    |                               | chain: INPUT                        |
|                      |      +==================+     |                                     |      +===============+
| table:               | -->  + Routing Decision + --> | table:                              | -->  + Local Process +
| raw -> mangle -> nat |      +=========+========+     | mangle -> filter -> security -> nat |      +===============+
+----------------------+                |              +-------------------------------------+
                                        |
                                        v
                        +------------------------------+     +---------------------+
                        | chain: FORWARD               |     | chain: POSTROUTING  |
                        |                              |     |                     |     +=========+
                        | table:                       | --> | table:              | --> + Network +
                        | mangle -> filter -> security |     | mangle -> nat       |     +=========+
                        +------------------------------+     +---------------------+

为了能使 FORWARD 生效，请确保 cat /proc/sys/net/ipv4/ip_forward 为1。

Outgoing 数据包

+===============+     +==================+     +----------------------+     +==================+     +--------------------+      +----------------------+     +=========+
+ Local Process + --> + Routing Decision + --> | chain: OUTPUT        | --> + Routing Decision + --> | chain: OUTPUT      | -->  | chain: POSTROUTING   | --> + Network +
+===============+     +=========+========+     |                      |     +=========+========+     |                    |      |                      |     +=========+
                                               | table:               |                              | table:             |      | table:               |
                                               | raw -> mangle -> nat |                              | filter -> security |      | mangle -> nat        |
                                               +----------------------+                              +--------------------+      +----------------------+

第一个路由判定主要是收集数据发送前的必要信息，比如所要使用的网卡、IP 地址以及端口号。当数据包触发了协议栈中的规则链时，内核将会遍历不同的功能表（顺序如上图所示），比如 Incoming 数据包触发 PREROUTING 规则链时，内核会先执行 raw 功能表中的 PREROUTING 规则链，其次 mangle 功能表，最后才是 nat 功能表。 Netfilter 还允许系统管理员创建自己的规则链，这样可以在内置的规则链中进一步划分规则。

规则

功能表包含了多条规则链，而每一条规则链包含多条规则。

规则包含了 匹配标准 和 具体动作。内核会依次遍历规则链中的规则。

当数据包满足某一条规则的匹配标准时，内核将会执行规则所制定的具体动作。

比如系统管理员设置了“来自a.b.c.d的连接可以接收”这样的一条规则，其中：

来自a.b.c.d的连接 指的是匹配标准
接收是具体动作

当具体动作只是用来 记录日志 或者 标记数据包 时，表明该动作不具有终结特性，内核还是会继续遍历规则链中剩下的规则。否则，当内核匹配上了具有终结特性动作的规则时，内核执行完具体动作之后，将停止遍历剩下的规则。

具体动作分为终结和非终结两种类型，其中非终结类型使用较多的一种是跳到自定义的规则链上遍历规则。

所谓终结特性是指不会影响到数据包的命运。所以条件越苛刻的规则应该放越前面。

当规则链中没有规则，或者是数据包没有满足任何一条终结特性的规则时，内核将会采用规则链的策略来决定是否接收该数据包。

策略一共有两种：接收和丢弃。从另外一个角度看，规则链的策略体现出访问控制策略的设计：通和堵。

对于通策略而言，整个系统的大门是关闭着的，只有系统管理员赋予你权限才能访问。而堵则是整个系统的大门都是敞开着的，而规则将用来限制一些用户的访问。

自定义的规则链并不存在策略，当出现没有规则匹配或者数据包不满足规则时，将会跳回上一级，类似于函数调用栈。

iptables

iptables 是 Netfilter 模块提供的命令接口，系统管理员可以通过它来配置各种访问控制规则。在定义规则时，可以参考以下模版。

# list rules in one table
# iptables -t table -nvL

# 查看 nat 功能表下规则
# iptables -t nat -nvL

# append new rule
# iptables [-t table] -A chain matchCretira -j action

# 系统管理员要限制来自 a.b.c.d IP 地址的访问
iptables -t filter -A INPUT -s a.b.c.d/n -j REJECT

# delete rule
# iptables [-t table] -D chain ruleNum

# 需要删除 filter/OUTPUT 的第二条规则
iptables -t filter -D OUTPUT 2

常用的具体动作有：

filter 功能表：ACCEPT／DROP／REJECT／RETURN／LOG
nat 功能表：SNAT／DNAT／REJECT／MASQUERADE／LOG

man iptables 能提供很多信息。但说明文档始终没有更新 nat 功能表添加了 INPUT 规则链。。。

初体验

为了保护本地环境以及模拟多节点环境，以下实验过程都在虚拟机上运行，并在虚拟机上利用Docker 来模拟多节点的环境。

# docker version | grep 'Version:' -B 1
Client:
 Version:         1.12.5
--
Server:
 Version:         1.12.5

整个网络模型如下图所示：

+---------------------------------------+
| +----------------+ +----------------+ |
| | Container #1   | | Container #2   | |
| | IP: 172.17.0.2 | | IP: 172.17.0.3 | |
| +-------------+--+ +--+-------------+ |
|               |       |               |
|               v       v               |
|           +---+-------+----+          |
|           | Bridge docker0 |          |
|           | IP: 172.17.0.1 |          |
|           +-------++-------+          |
| The               ||                  |
| Box     +--------------------+        |
+---------| Host-Only  Adapter |--------+
          | IP: 192.168.33.100 |
          +--------------------+

整个网络将虚拟机作为防火墙，初始状态下，不开放任何端口，将 filter 的三条内置链的策略为 DROP。

# iptables -t filter -P INPUT DROP
# iptables -t filter -P OUTPUT DROP
# iptables -t filter -P FOPWARD DROP

设置完以后，你会发现你连 ping 都 ping 不通了。。。

$ wfu at wfu-mac in ~/workspace/docs
$ ping -c 3 192.168.33.100
PING 192.168.33.100 (192.168.33.100): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1

--- 192.168.33.100 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

接下来的任务是能在 Mac 本地访问虚拟机里的 Docker Container，其中 Container 的启动方式如下。

# docker run -it -d ubuntu-nw python -m SimpleHTTPServer 8000
3301547d70b356223688fd9e38a1925ba90028084a44775bf79422be624c486b

# docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
3301547d70b3        ubuntu-nw           "python -m SimpleHTTP"   9 seconds ago       Up 8 seconds                            boring_borg

开放22端口

这台虚拟机默认是没有开启桌面。

# stty size
25 80

在25 * 80这样的窗口里操作系统实在是太痛苦了。在不启动桌面的情况，有必要通过远程登陆来改善下体验。

虚拟机上已经预先装好了ssh server，只需要开放22端口即可。

# iptables -t filter -A INPUT -d 192.168.33.100 -p tcp --dport 22 -j ACCEPT
# iptables -t filter -A OUTPUT -s 192.168.33.100 -p tcp --sport 22 -j ACCEPT

为什么需要两条命令？

回顾之前的内容，数据包穿过 INPUT 规则链后会被本地程序所消费。该数据包的生命周期就结束了，访问者接收到的数据包是本地程序所产生，这两者需要区分开。第一条命令是系统管理员发给访问者的数据包的通行证，数据包到达 ssh server 之后就不复存在了，通行证也就不存在了。 ssh server 产生的数据包系统并不认识，它在穿过 OUTPUT 规则链时，如果没有通行证的话，就会被内核“吃掉”，永远都回不到访问者。这需要两边都打通才能形成一个回路。

好了，马上登陆虚拟机。

$ wfu at wfu-mac in ~/workspace/docs
$ ssh root@192.168.33.100
root@192.168.33.100's password:
Last login: Fri Mar  3 18:04:55 2017 from 192.168.33.1
[root@localhost ~]# stty size
72 278

可以在必要的时候记录日志。

比如 iptables -t filter -I INPUT 1 -p icmp -j LOG --log-prefix 'filter-input:'，只要 ICMP 数据包触发了 filter 功能表中的 INPUT 规则链，那么系统将会记录下该数据包的基本信息。

然后通过 tail -f /var/log/messages 来查看日志。

如何访问容器

在创建 Container 的时候，如果不制定 Network 类型，那么 Daemon 会自动将 Container 挂到 docker0 下面，并形成了一个 172.17.0.0/16 子网。

# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
6786e7d4c36a        bridge              bridge              local
f16e611d5715        host                host                local
912ae96541e9        none                null                local

# docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "6786e7d4c36acbd9d359289f90bd737bfcb21e74a5e467769e45fa9f732954f2",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

而 Mac 和虚拟机在 192.168.33.0/24 子网内，想要在 Mac 访问虚拟机上的 Container，需要用 Destination NAT 转发请求，所以只需要关注 PREROUTING／FORWARD 这两条规则链即可。

Docker Daemon 启动以后会自动在 Netfilter 添加访问控制规则。

# iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 1 packets, 128 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER     all  --  *      *       0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT 1 packets, 128 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  docker0 *       0.0.0.0/0            0.0.0.0/0

PREROUTING 规则链只有一条规则，只要目的地址是本地地址，就跳到 DOCKER 这条自定义规则链中。 DOCKER 规则链中，只要数据包到达 docker0 网卡，就直接返回到上一层。

Mac 发来的数据包不会直接到达 docker0 网卡，而是 enp0s8 网卡。所以需要在 DOCKER 规则链中添加对来自 192.168.33.0/24 的 Destination NAT 规则。

nat 功能表中 OUTPUT 规则链是用来对本地数据进行 DNAT／REDIRECT 操作，因为系统内部的通信一般情况不会穿过 PREROUTING。而在 DOCKER 规则链中添加对外部地址的 DNAT 规则并不会在 OUTPUT 规则链中被匹配。

一旦通信双方通过 nat 功能表建立连接，内核将不会使用 nat 功能表上的规则过滤该连接上的数据包。

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:20:9f:cb brd ff:ff:ff:ff:ff:ff
    inet 192.168.33.100/24 brd 192.168.33.255 scope global enp0s8
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe20:9fcb/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:c3:e1:87:ab brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever

数据包经过 PREROUTING 规则链之后，被路由到了 FORWARD 规则链。

数据包在 enp0s3 网卡与 docker0 网卡的转发，会匹配到 FORWARD 规则链的第3和第4条规则，这里不需要额外的配置。

# iptables -t filter -xnvL
Chain INPUT (policy ACCEPT 9 packets, 548 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
     108    13856 DOCKER-ISOLATION  all  --  *      *       0.0.0.0/0            0.0.0.0/0
      58     3736 DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
       0        0 ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
      50    10120 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
       0        0 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 7 packets, 744 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain DOCKER (1 references)
    pkts      bytes target     prot opt in     out     source               destination

Chain DOCKER-ISOLATION (1 references)
    pkts      bytes target     prot opt in     out     source               destination
     108    13856 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

根据上面的分析，我们只需要添加下面一条规则，便可访问该 Container。

# iptables -t nat -A DOCKER -p tcp -i enp0s8 -d 192.168.33.100 --dport 80 -j DNAT --to-destination 172.17.0.2:8000

访问结果如下。

$ wfu at wfu-mac in ~/workspace/docs
$ curl 192.168.33.100
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html>
<title>Directory listing for /</title>
<body>
<h2>Directory listing for /</h2>
<hr>
<ul>
<li><a href=".dockerenv">.dockerenv</a>
<li><a href="bin/">bin/</a>
<li><a href="boot/">boot/</a>
<li><a href="dev/">dev/</a>
<li><a href="etc/">etc/</a>
<li><a href="home/">home/</a>
<li><a href="lib/">lib/</a>
<li><a href="lib64/">lib64/</a>
<li><a href="media/">media/</a>
<li><a href="mnt/">mnt/</a>
<li><a href="opt/">opt/</a>
<li><a href="proc/">proc/</a>
<li><a href="root/">root/</a>
<li><a href="run/">run/</a>
<li><a href="sbin/">sbin/</a>
<li><a href="srv/">srv/</a>
<li><a href="sys/">sys/</a>
<li><a href="tmp/">tmp/</a>
<li><a href="usr/">usr/</a>
<li><a href="var/">var/</a>
</ul>
<hr>
</body>
</html>

docker run -it -d ubuntu-nw -p 80:8000 python -m SimpleHTTPServer 8000 能帮我们完成这次访问，可以观察 Docker Daemon 都为我们做了什么。