LWN：处理文件系统的可中断特性！

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

Handling filesystem interruptibility

By Jake Edge
August 5, 2024
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/983714/

David Howells 希望在 2024 年的 Linux 存储、文件系统、内存管理和 BPF 峰会 上讨论更改文件系统代码在需要打断或终止某个操作（operation）的支持方式，以解决网络文件系统和其他文件系统中的一些长期存在的问题。正如他在 会议提案 中提到的，一些文件系统可能期望不被打断，但它们的调用代码可能会获取一些可中断 (或可终止) 的锁和互斥量，这实际上会错误地改变当前 task 的状态。他希望找到一种解决这个问题的方法。

这里的可中断性（interruptibility）是指对 signal 的处理。可中断进程会响应任何未被屏蔽或忽略的信号。而可终止（killable）是可中断的一种变体，它只响应致命信号（fatal signal）。

有许多使用了 *_interruptible() 和 *_killable() 变种方式来获取锁的地方，但它们会导致更高层级使用的不可中断设置被覆盖掉。Howells 表示，无法采用某种大规模的更改来解决这个问题，因此需要逐步进行。他提议一项为期多年的努力，使用显式的 begin 和 end 函数来括起不可中断区域，这类似于禁用硬件中断的方式。代码可以禁用可中断性，这将用计数器进行跟踪，然后在关键部分结束后重新启用它。

例如，一个 overlayfs 文件系统可能包含一个网络文件系统作为背后的多个层级之一。overlayfs 可能不会获取可中断锁，但网络文件系统可能会这样做，这会导致相应的文件操作以 overlayfs 未能意料到的方式被中断。Ted Ts'o 认为，类似于上述的更改在某些情况下可能有用，但他不认为“这是我们想要在所有地方都使用的”。例如，特定信号量（mutex）的可中断状态对于获取它的代码来说是局部的。不像 切换到 GFP_NOFS 的工作，其最终计划是将所有内容转换为使用它，这种更改只需要针对特定的调用。

Kent Overstreet 和 Dave Chinner 都要求提供更多关于所解决问题的具体示例以及代码需要如何更改以适应 Howells 的提议。Howells 说，他遇到的最大问题是 sendmsg() 是可中断的，但 NFS 文件系统可能会被挂载为不可中断的。“NFS 认为它不可中断，但它是因为使用了网络接口。”他指出，这个转换最终将意味着许多可中断 (和可终止) 的锁和互斥量函数变体可以被移除。

Chinner 和其他人反对，说仍然需要这些变体。还有一些反对意见，因为许多对 mutex_lock_interruptible() 的调用没有检查错误返回值，虽然有几个人同时说话，这使得跟踪变得有些困难。Al Viro 还担心由于提议的更改而导致的死锁。

Viro 说，处理信号 (例如来自使用 control-C 的人) 是网络函数调用者的责任；一个带有 -o hard 的 NFS 挂载不希望也不期望它的操作被中断，然而 Howells 说。调用 mutex_lock_interruptible() 只会将可中断性应用于该特定调用，Wedson Almeida Filho 和 Ts'o 说，而不是应用于它和解锁调用之间的整个区域。Ts'o 说，如果没有一个特定的补丁更改特定代码路径中的问题，与会者将很难确定它是否合理；同时，他重申，他没有看到进行大规模更改的理由。

Viro 问，与其调用括起不可中断区域，为什么不直接为该区域禁用信号呢？但 Howells 说 SIGKILL 不能被屏蔽，虽然 Christian Brauner 指出，内核可以屏蔽该信号，即使用户空间无法屏蔽。

Jan Kara 同意整体方法，说对于不期望被中断的调用者来说，确实存在一个问题。但 Brauner 担心，有人看到 sendmsg()，它显然是可中断的，如何才能识别出它在某些情况下可以以不可中断的方式被调用。Howells 承认这可能是一个问题。

Chinner 建议有一个不可中断的 sendmsg() 变体，但 Howells 说，像 sendmsg() 这样的多个调用都受到了影响。“不可中断状态的文档与我们需要应用该状态的地方完全脱节，”Chinner 说。它需要在调用这些函数的任何地方添加大量注释，描述这种情况是如何发生的以及哪些代码路径受到影响。“否则，它是不可维护的。”

Viro 说，在他看来，Howells 想要的是能够在某些时候暂停网络代码中的信号传递。 TASK_INTERRUPTIBLE 和 TASK_UNINTERRUPTIBLE 状态是为休眠进程准备的，Viro 继续说道，当任务被唤醒时，这些状态会发生改变，但真正想要的状态“闻起来像'我想要信号传递被暂停'”，直到代码区域结束。

Ts'o 同意，指出这种更改可以在不添加新的基础设施和任务标志的情况下完成。Howells 说，操纵信号掩码会影响进程中的其他线程，不过 Ts'o 承认这是一个问题。Viro 说，一个替代方案可能是简单地在进行信号传递时跳过有问题的线程；“基本上就是在说'别烦我'”。

会议时间到此结束，但出现的情况是，需要补丁来集中讨论。截至目前，2024 年 LSFMM + BPF YouTube 播放列表 中还没有关于本次会议的视频。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

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

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～