如何在 Linux 上通过 C API 判断给定的 fd 的类型？

2024年5月20日 219次阅读 来源: spacewander

最近接到一个任务，需要判断传过来的 fd 是不是属于 eventfd/signalfd 这一类特定的 fd。因为这一类 fd 不支持某些操作，如果调用时不加判断，会报 Invalid Argument 错误。按理说，如果能把 fd 类型作为一个额外的参数传进来，就能轻松解决问题了。不过因为一些限制，拿到手时只有 fd 这一个整数。好在需要过滤的地方不在重要的路径上，所以 hack 一点的办法应该也能被接受。

既然 Linux 能够根据一个整数 fd 调用特定的操作，那么内核层面上一定会有一个 fd 到实际文件类型的映射。所以最好的打算，就是 Linux 把这个映射通过 syscall 的方式暴露出来了，然后我只要调用它，就能完成工作了。可惜找了一段时间，依然没有找到对应的 syscall。看来是不存在这样的好事了。

补充一个前提，我正在编写的是 C 代码。如果写的是脚本的话，至少有两种方法可以获取特定 fd 的类型。

一种是调用 lsof -p $pid -a -d $fd：

 ￥ lsof -p 16166 -a -d 15
COMMAND   PID USER   FD      TYPE             DEVICE SIZE/OFF       NODE NAME
xxxxx   16166  lzx   15u  a_inode               0,13        0      10094 [eventfd]

我们可以看到 进程 16166 的第 15 号 fd 是一个 eventfd。

另一种是调用 cat /proc/$pid/fdinfo/$fd

 ￥ cat /proc/16166/fdinfo/16
pos:    0
flags:    02004002
mnt_id:    13
sigmask:    0000000000010000

该操作并不会直接显示 fd 的类型。但是因为不同类型的 fdinfo 格式不一样，你可以根据 man procfs 里面的说明，解析出具体 fd 的类型。比如 进程 16166 的第 16 号 fd 是一个 signalfd。

毫无疑问，对于 C 程序，上面两种方法都不太合适。虽说并不是无法实现，但是你让一个 C 程序每次判断 fd 类型时都要读完整个 fdinfo 文件，然后再通过一个 parser 解析出具体的 fd 类型，无论从性能上还是代码量上都不可接受。

也许存在某个 API，可以直接获取 fd 类型？为什么不看看神奇的 lsof 的源码呢？

抱着源码里可能隐藏着谜底的想法，我下载了 lsof 的代码。打开底下一个名为 linux 的文件夹，看了里面的文件几眼，我感觉被欺骗了。

没想到 lsof 你这个浓眉大眼的，居然也是用读 /proc 的方式来获取 fd 信息的!
看来这条路也断了。难道真的非得去解析 fdinfo 不可吗……

仔细看多几眼，lsof 貌似只是从 /proc/$pid/fd 里面读取了基本的信息。有些信息，比如我想要的 NAME，不是直接从那里面获取的。看来还是有希望的。我试着找找看，看看有什么关键的操作。

以下略去一些曲折的碰壁和反复的试错…… 反正我费了若干个小时，走了些弯路，终于明白汲汲以求的 NAME 是怎么得到的。其实就是 readlink /proc/$pid/fd/$fd!

对于 regular file，readlink /proc/$pid/fd/$fd 返回的是文件路径。而对于 eventfd/signalfd 这一类不可能有真正的 inode 的文件，返回的是 anon_inode:[eventfd]。于是我需要做的事情相对简单了：
先拼接 readlink 的文件名参数，然后调用 readlink，解析返回来的文件名。由于我只需要知道某个整数 fd 在本进程内的类型，可以用 /proc/self 代替 /proc/$pid。这么一来，我就只需要拼接后面的 $fd 部分。因为 fd 是一个整数，整个文件名 buffer 大小是有上限的，而且这个上限不大。所以可以把这个 buffer 弄成静态分配的，不用操心内存管理。接下来是 readlink 这个系统调用，原来最好的打算里面，也是逃不开一次系统调用的，所以这部分不算额外的开销。最后是对返回文件名的解析，凭借该文件名有着固定前缀的特性，我们可以先 strncmp 判断是否是 anon_inode:[，接着一路解析出方括号内具体的 fd 类型。也不是很难就是了。

后来看了相关的内核代码，估计应该不会有更好的方法了。

下面是 eventfd 创建代码：

    /* fs/eventfd.c */
    struct file *file;
    ...
    file = anon_inode_getfile("[eventfd]", &eventfd_fops, ctx,
                  O_RDWR | (flags & EFD_SHARED_FCNTL_FLAGS));

你可以这么认为，anon_inode_get_file 返回了 file 的一个实例，而这个实例组合了 eventfd_fops 这个 eventfd 功能的具体实现。eventfd 之所以跟其他 fd 不同，全靠 eventfd_fops 里面定义的方法。如果内核要想提供一个 API，返回某个 fd 的类型，最好是每个 fd 都实现返回自己的类型方法。但是 eventfd_fops 这个结构体里面，没法返回 eventfd 标识的方法。有一个 show_fdinfo 的方法，不过这个方法是提供给 /proc/$pid/fdinfo 展示用的。另外 eventfd_fops 这个结构体是 static 的，所以也排除存在 if (file_operation == &eventfd_fops) return enum_eventfd; 这样的代码的可能性。

signalfd 的情况也差不多。

最后我没有采用 readlink 的方式，而是改由创建特殊 fd 的代码顺便把 fd 编号记录下来，接收到 fd 之后，我再去查找，看看是否是特殊的 fd。

    原文作者：spacewander
    原文地址: https://segmentfault.com/a/1190000015186817
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞