LWN：调查文件系统的错误来源！

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

Tracing the source of filesystem errors

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

在 Linux 内核中，许多地方会向用户空间返回 EINVAL (无效参数) 错误码，但往往难以确定实际的根本问题，因为 errno (错误码) 的错误代码过于笼统。Miklos Szeredi 在 2024 年 Linux 存储、文件系统、内存管理和 BPF 峰会 (Linux Storage, Filesystem, Memory Management, and BPF Summit) 上远程主持的文件系统会议中，就想要讨论这个问题。他希望帮助那些试图调试问题的人追踪内核中特定错误代码的生成位置。

文件系统挂载就是这类问题的一个例子，Szeredi 说；在许多地方会返回 EINVAL ，所以这个错误码并没有真正告诉任何人任何信息。如果他正在调试一个内核文件系统并收到错误，那么开发者就会想知道该错误发生在代码中的哪个位置。 strace 工具对于调试很有用，所以理想情况下，无论采取什么措施来帮助显示错误来自哪里，都应该与它集成。

他认为添加类似的东西并不困难，尽管最好能够得到不需要 root 权限的解决方案。他提到了现有的解决方案，包括 dmesg 中的消息，但这些消息“不适合调试”。对于使用新的挂载 API 的文件系统，从 fsopen() 返回的文件描述符可以用来读取错误消息。

另一种可能性是使用 ftrace (函数跟踪器)，它可以用来追踪某些错误的来源，但他表示， tracefs 接口很难使用。 trace-cmd 工具是一个更友好的接口，但它还不支持 funcgraph-retval 选项（即 function_graph tracer 获取所需信息的途径）。如果 trace-cmd 有一个选项可以过滤负返回值，那就更好了，这个选项应该很容易添加。但它需要 root 权限并且具有全局范围，这使得它难以与 strace 集成。

他探讨了 strace 友好的解决方案可能是什么样子。他建议在 struct task_struct 中添加一个错误描述符，以便在发生错误时，代码可以使用 current->err_desc 来存储一个包含错误生成位置信息的字符串。他表示，这应该对性能没有多大影响，因为错误路径不应该经常被跟踪。他想知道是否添加的任何消息都需要成为内核 ABI 的一部分，因此不可更改，或者它们是否可以包含，比如，源文件名和行号，这些显然会发生变化。

作为一个实验，他尝试重新定义 EINVAL 和其他错误代码为宏，这些宏将使用源文件名和行号创建一个 tracepoint，但在这样做时遇到了多个问题。例如，这些值在 switch 语句、条件表达式以及用错误代码预设变量中使用；在每种情况下，宏替换都会导致编译或其他问题。

另一种方法是对错误代码的不同使用方式使用不同的宏，因此在返回语句中也许可以使用 ERR_TRACE() 来放置跟踪点。他的幻灯片中展示了更多关于这些宏的示例，这些示例可以在 YouTube 视频中看到。这种更改的问题在于，它必须手动完成，会增加复杂性，并会导致大量代码改动。

但 Amir Goldstein 认为，代码改动将“仅仅局限于感兴趣的人”，因为它只会在维护者有兴趣获得额外信息的情况下，由维护者对其子系统进行改动。Kent Overstreet 说，重构可以使用 Coccinelle 来完成，而不是手动完成。他还认为，这可能与他一直在做的内存分配配置文件工作中最近合并的基础设施有一些重叠；他在 bcachefs 中使用了大量的错误代码，这些错误代码实际上在其中都编码了源文件名和行号，尽管它们在返回到用户空间之前都被映射到常规的 errno 值了。

Aleksa Sarai 不确定仅仅获得错误代码设置位置这一个数据是否真的有帮助。在他的调试经验中，通常需要查看整个调用栈，就像使用 ftrace 一样。

Ted Ts'o 说，尚不清楚此功能的用例是什么；是针对未来某个 RHEL 内核中的最终用户，还是针对文件系统开发人员，或者完全是为了其他用例？他说，根据用例的不同，权衡结果也有所不同。Omar Sandoval 作为一名用户空间开发人员，表示他希望看到一种简单的方法来获取一个字符串，该字符串指示 EINVAL 的生成位置，而不必处理跟踪点或 =ftrace=。

Szeredi 说，他认为这个功能的目标是那些正在调试这些问题的开发人员，可能是远程调试。这是他个人最常遇到的用例。他可以看到，它可能对向应用程序返回信息也有用。

Christian Brauner 说，他可能在过去几年中为内核添加了 50 个或更多 EINVAL 返回；每次他这样做时，他都会想知道是否应该添加一个 pr_info() 调用，其中包含一些额外的信息。他说，传统上，其他内核开发人员会在添加包含更多信息的额外调用时抱怨，但如果他在用户空间处理自己的项目，他会每次都添加它们。然而，有些人认为它们是 dmesg 中的噪音。

Goldstein 想知道内核如何为 C 库 (libc) 提供对包含源文件名和行号的字符串的访问权限。用户空间程序访问 errno 并使用 strerror() 来获取更多信息，因此内核需要通过 libc 可以访问的机制提供任何额外信息。Szeredi 提出将一个字符串放在 struct ptrace_syscall_info 中，但 libc 无法访问它。

Overstreet 说，bcachefs 的新错误代码“非常有用”；他尽量不重复使用这些代码，因此它们实际上指示了代码位置。David Howells 说，libc 机制可以是一个新的系统调用来检索附加信息；或者用户空间可以向内核注册一个针对每个线程的字符串缓冲区，用于存储该信息。Ts'o 回到了用例问题；一些用户只对高级摘要消息感兴趣，而开发人员可能想要一系列低级错误消息。这两种用例有不同的要求，他担心讨论变得复杂，因为它试图同时解决这两个问题。

说到复杂性，Howells 指出，错误也可能来自远程来源，例如来自网络文件系统。这似乎使讨论接近尾声，尽管目前尚不清楚是否已经做出任何决定。这个会议是在峰会第三天也是最后一天的末尾进行的，所以参加者可能已经筋疲力尽了。

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

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

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