LWN：futex robust list 的 API 变更

关注了就能看到更多这么棒的文章哦～

Jake Edge
 Gemini translation
 原文链接：https://lwn.net/Articles/1056387/ 

由 Jake Edge 发表
 2026 年 2 月 4 日 

LPC 

健壮 futex (robust futex) 内核 API 是一种让用户空间 (user-space) 程序确保其持有的锁在退出时能被正确清理的方法。但正如 André Almeida 在东京举行的 2025 年 Linux Plumbers Conference (LPC) 的 “Gaming on Linux” 微型会议 (microconference) 会话 (session) 中所描述的那样，该 API 存在许多不同的问题。他提出了一些关于新 API 的想法，旨在解决其中的许多问题，并希望与参会者进行讨论；此外，他还想谈谈一个难以触发的竞态条件 (race condition)。 

“几年前，我为 futex 开发了一个新 API，”Almeida 在开场时说道，“那么为什么不也为健壮列表开发一个新 API 呢？”他所指的是在 2022 年并入 5.16 内核的新 futex API，其形式为 futex_waitv() 系统调用 (system call)（文档）。futex2 API 的其他一些部分（相关文章）已随 2024 年的 Linux 6.7 发布。 

SteamOS 发行版 (distribution) 是 Linux 游戏开发工作的主要阵地，其游戏所使用的二进制接口 (ABI) 是 x86 架构上的 Windows ABI。虽然大多数游戏是为该 ABI 构建的，但 SteamOS 也可以在 Arm64 上运行，这带来了“许多有趣的挑战”。除了提供 Windows ABI 的 Proton 兼容层 (compatibility layer) 之外，它还添加了 FEX 模拟器 (emulator) 以在 Arm64 处理器上运行 x86 二进制文件。这对内核的各个领域都有影响，包括 futex、内存管理和文件系统。 

FEX 是一种即时编译 (JIT, just-in-time) 编译器，用于将 32 位和 64 位的 x86 指令转换为 Arm64 机器代码。作为其中的一部分，当它发现 syscall 指令时，需要将其翻译为 Arm64 系统调用，但这对于某些 x86-32 系统调用的效果并不理想。FEX 项目有一个维基页面描述了这些存在问题的调用，其中之一就是 set_robust_list()。 

set_robust_list() 用于避免当 futex 持有者在释放锁之前死亡时出现的问题，这种情况会导致等待该锁的其他线程陷入饥饿。因此，当线程获取锁时，它可以将该锁添加到健壮列表中，这是一个在用户空间维护的链表 (linked list)。线程使用 set_robust_list() 告知内核该列表头的位置。内核中线程的退出路径利用这些信息来唤醒列表中每个 futex 的所有等待线程；它还会为每个 futex 添加 FUTEX_OWNER_DIED 标记。他提到的另一个细节是，在执行操作（获取或释放锁）期间，但在链表更新之前，futex 可以被放入列表头的一个“待处理 (pending)”字段中，以便在此时发生崩溃时仍能进行清理。 

为什么要变更？

他说，出于几个原因，需要一个新的 API。首先，与 x86 不同，Arm64 不同时具备 32 位和 64 位系统调用，因此模拟 32 位应用程序非常困难——因为缺少“兼容 (compat)”系统调用。例如，64 位系统调用无法处理 32 位的健壮列表，因为由于指针大小 (pointer size) 不同，它无法解析该列表。因此需要一个新接口，允许用户空间通知内核这是 32 位还是 64 位的健壮列表，以便内核能够正确解析。 

现有接口的另一个缺点是，一个线程只能设置一个健壮列表，但 FEX 也想使用健壮 futex。如果应用程序已经使用了它们，FEX 就必须在两者之间做出选择。新接口将提供一种为一个线程设置多个列表头的方法。 

目前，内核处理的健壮列表项有 2048 个的限制，这是为了避免陷入无限循环。但这一限制从未作为 API 的一部分记录在案，因此用户空间程序并不知情，这导致了针对 GNU C 库的一个错误报告 (bug report)。他说，在新的 API 中，要么应该将该限制记录并作为 API 的一部分公开，要么应该通过引入针对循环列表的对策来取消这一限制。 

最后一个问题“更有趣”但也“有点难以解释”；这是一个在解锁 futex 时可能发生的竞态条件 (race condition)。解锁健壮 futex 的正常步骤如下： 

1. 将 futex 的地址放入健壮列表的待处理 (pending) 槽位中

2. 从健壮列表中移除该 futex

3. 执行底层解锁，清除 futex 并唤醒等待它的任何线程

4. 清除待处理槽位

然而，在第三步和第四步之间，另一个线程可能会认为自己是该 futex 的唯一使用者，从而决定释放它。那个线程随后可能会在原 futex 所在的同一位置分配内存。接着，正准备执行第四步的原线程死亡，导致内核在 futex 处写入 FUTEX_OWNER_DIED，从而损坏了某些随机内存。这很难复现，但它确实会发生。 

Almeida 表示，他不确定该如何解决这个问题。也许将退出路径与线程发起的所有 mmap() 和 munmap() 调用进行串行化是一种可能。另一个想法可能是以某种方式改变围绕待处理字段的 API，以避免这种竞争。前一天他参加了可扩展调度器类 (sched_ext) 微型会议，这让他想到也许可以编写一个专门的调度器来可靠地复现该问题；这将有助于修复过程，也可以转化为测试用例。 

新 API

他在会话中提出的 API 似乎比他在 2025 年 11 月（LPC 前几周）发布的第 6 版补丁集又有所演进。它包含两个新的系统调用： 

●●●
..set_robust_list2(struct.robust_list_head.*head,.unsigned.int index,
...................unsigned.int cmd,.unsigned.int flags);
...................
..get_robust_list2(int.pid,.void **head_ptr,
...................unsigned.int index,.unsigned.int flags);

index 参数用于区分不同的列表，以便库和应用程序可以拥有各自的列表。set_robust_list2() 的 cmd 参数可以是 CREATE_LIST_32（或 64），以使用 head 指针创建相应位数 (bitness) 的列表；在这种情况下，调用会返回一个与该列表关联的未使用索引。通过传递感兴趣的索引，可以使用 SET_LIST_32（或 64）命令覆盖列表。LIST_LIMIT 命令返回每个任务支持的列表数量。（所有这些命令名称的全称据推测都会包含 FUTEX_ROBUST_LIST_CMD_ 部分。）get_robust_list2() 将仅返回给定 pid 和 index 的健壮列表头（存入 head_ptr）。 

讨论

随后，Almeida 开始征求提问和评论。Liam Howlett 指出，健壮列表的退出路径需要内核中的内存不足 (OOM, out-of-memory) 处理延迟，因此可以通过将 OOM 处理延迟设为零并触发任务的 OOM-kill 来更轻松地复现该竞态条件。glibc 维护者 Carlos O'Donell 表示，虽然这可能是真的，但这并不能真正引向竞态条件的解决方案，他和 musl libc 项目的 Rich Felker 都曾研究过这一问题。如果要推出新的 API，那么这就是坐下来研究出妥善解决方案，并确定现有 C 库如何随着时间的推移过渡到新接口的“绝佳机会”。 

“情况还会变得更糟，”Howlett 说道。正在退出的任务可能会被控制组 (control-group, cgroup) 子系统冻结，这意味着 OOM 处理程序可能需要无限期等待才能清理现场。他说，这是在创建新 API 的过程中应该理清的另一个环节。 

O'Donell 说，新 API 的使用者需要能够注册与内核共享的结构体中的位数，这很有道理。他询问是否应该考虑 32 位或 64 位以外的大小，但 Howlett 指出提案 API 中有一个未使用的 flags 参数，如果需要的话可以使用。 

对话转回了 OOM 处理程序的延迟，似乎没人能完全理解它。O'Donell 想知道这是否是为了修复 Almeida 所担心的竞态条件在其他背景下出现时所做的尝试。Howlett 表示，他认为这是为了在退出处理代码处理健壮列表之前，阻止 OOM killer 释放持有锁的内存。Sebastian Siewior 表示他也不清楚为什么要添加这个延迟，但他会将其列入调查清单。 

关于 OOM-killer 延迟的起因和方式还有一些进一步的讨论，但会议时间已到。感兴趣的读者可能想参考演讲的 YouTube 视频和 幻灯片。总的来说，参会者似乎一致认为需要新的 API，并且没有听到对其拟议形式的实质性抱怨，但在进入上游之前显然仍有一些细节需要敲定。 

[ 我要感谢我们的差旅赞助商 Linux 基金会，感谢他们资助我前往东京参加 Linux Plumbers Conference。] 

LWN 评论概述：

文章底部的评论主要探讨了跨架构兼容性和多运行时协作的问题。一位用户询问是否可以增加对大端和小端（endianness）转换的支持，因为 QEMU 的用户态模式在模拟异构架构时也会遇到健壮列表布局不匹配的问题。另一位用户则关注多个用户空间运行时之间的协作，指出目前每个线程只能有一个健壮列表，而 libc 并没有提供与其他原生 futex 使用者集成的机制，并对比了已经实现多用户支持的 rseq 接口。 

欢迎分享、转载及基于现有协议再创作～