01

唯有文件得人心

当一个女生让你替她抓100只萤火虫,她一定不是为了折磨你,而是因为她爱上了你。当你们之间经历了无数的恩恩怨怨和彼此伤害,她再次让你替她抓100只萤火虫,那一定是因为她还爱着你。

 

 

为什么?因为这就是套路,是在下偶尔瞟一眼古装肥皂剧总结出来的套路。

 

Linux里面最大的套路,就是“一切都是文件”。爱一个人,就为她捉萤火虫;做一件事,就让它成为一个“文件”。

 

为什么自古深情留不住,唯有“文件”得人心呢?因为文件在用户态最直观的形式是随着一次open,获得一个fd,有了这个fd,长城内外,你基本可以为所欲为:

 

在本进程内,fd的最直观操作是open、close、mmap、ioctl、poll这些。mmap让你具备把fd透射到内存的能力,所以你可以通过指针访问文件的内容。再者,这个mmap,如果底层透射的是framebuffer、V4L2、DRM等,则让我们具备了从用户态操作底层显存、多媒体数据等的能力;比如,无论是V4L2还是DRM,都支持把底层的dma_buf导出为fd。poll则提供给用户阻塞等待某事件发生的能力。至于ioctl,就更加不用说了,你可以透过ioctl灵活地为fd添加控制命令。

 

在跨进程的情况下,Linux支持fd的跨进程socket传输,从而可以实现共享内存、dma_buf跨进程共享等。比如一个进程可以通过send_fd可以把fd发送出去:

 

 

而另外一个进程可以通过recv_fd把fd收过来:

 

 

这种fd在长城内外可以互访,fd最终可以指向dma_buf同时可以被mmap,而dma_buf又最终可以被显卡、显示控制器、video decoder/encoder等设备访问的能力,让fd打通了设备、CPU和跨进程的障碍,从此可以横着走。

 

 

我们在《宋宝华:世上最好的共享内存(Linux共享内存最透彻的一篇)》一文中已经详细阐述过这个过程,这里我们就不再赘述了。本文的重点在于匿名inode。

 

02

inode源头file活水

我们把文件想象成一个object,那么inode描述的是本源,和最终的object一一对应;dentry是inode的一个路径马甲,比如我们可以通过"ln"命令为同一个inode创建很多的硬链接马甲;而file则是活水,进程对object的一次“open”,获得一个file,导致用户态得到一个"fd"的句柄来操作这个object。

 

经典的inode、dentry、file谁都不缺席的模型是这样的:

 

 

 

上图中,我们有一个inode,这个inode有2个dentry,进程A、B open的是第一个dentry;而进程C、D open的是第二个dentry。变了的是file和fd,不变的是inode,中间的dentry马甲没那么重要。

 

但是在inode、dentry、file这个经典铁三角中,从来都是可以有一个缺席者的,那就是dentry,因为,有时候用户态想获得长城内外行走的便利,但是却不想这个inode在文件系统里面留下一个路径的痕迹。简单来说,我希望有个fd,但是这个fd,你在从"/"往下面搜索的任何一条路径下,你都找不到它,它根本在根文件系统以下不存在路径,它是无名氏,它没有马甲,它是个传说。

 

比如,近期名震江湖的剑客usefaultfd允许我们在用户空间处理page fault,我们是通过userfaultfd这个系统调用先获得一个fd,之后就可以对它进行各种ioctl了:

 

 

我们透过userfaultfd系统获得了一个fd,它在/xxx/yyy/zzz这样的文件系统下没有路径。这种情况下的fd,对应着的是一个没有名字的匿名inode,你显然没有办法像fd = open ("xxx", ..)那样来得到匿名inode的fd,因为"xxx"是一个路径,而匿名inode没有xxx,所以你是直接透过syscall userfaultfd这样的系统调用,来获得anon_inode在你的进程里面对应的fd的:

 

 

人过留名,雁过留声;杀人者,打虎武松也。但是anon inode不吃这一套,它是一个绝顶的轻功高手,它给与的,是透过fd长城内外行走的能力,但是,在文件系统里面却从未来过。这是用户真实的需求,如果这种需求一定要透过一个dentry的open才能实现,这未免有点画蛇添足了。

 

03

匿名inode的内核实例

我们接下来可以随便打开个anon inode的实例来看看它是怎么工作的了。首先userfaultd是一个系统调用:

 

 

这个代码里面比较核心的是就是,它通过:

 

anon_inode_getfd_secure()

 

生成一个匿名inode,并获得一个句柄fd。重点别忘记了,这种“文件”也是可以有file_operations的,比如上面anon_inode_getfd_secure()参数中的userfaultfd_fops:

 

 

这样,我们就可以在file_operations的ioctl,poll,read等callback里面实现自己特别的“文件”逻辑,这是我们自由发挥的舞台。

 

说起anon_inode_getfd_secure(),它再往底层走一级是__anon_inode_getfd():

 

 

进而再走一级是__anon_inode_getfile():

 

 

所以本质上,是先造一个anon_inode,然后再在这个anon_inode上面造一个pseudo的file,最后通过fd_install(fd, file),把fd和file缠在一起。再次强调,用户有了这个fd就可以为所欲为;而内核本身,则是通过file_operations的不同实现来为所欲为的。

 

anon_inode之上添加一个系统调用,造一种特殊的fd,让用户去poll,去ioctl,把想象空间拉大了。这种实现方法,如此拉风灵活,以至于它本身也成为了一种套路。比如内核里面fs目录下的:

 

 

eventfd,eventpoll,fscontext,io_uring,fanotify,inotify,signalfd,timerfd.......

 

正所谓, 待到秋来九月八,我花开后百花杀。冲天香阵透长安,满城尽带黄金甲。文件,哪怕最终是匿名的,都以冲天的香阵,弥漫整个Linux的世界。

 

04

用户使用匿名inode

到了要说再见的时刻了,用户可见的就是fd,通过fd来使用匿名inode。下面我们来制造一个page fault的例子,让用户态来处理它,这个例子直接简化自userfaultfd的man page。我们在主线程中,通过mmap申请一页内存,然后通过userfaultfd的ioctl告诉内核这页的开始地址和长度,以及通过UFFDIO_REGISTER告诉内核这页的page fault想用户空间处理:

 

 

然后我们在pthread_create()创建的fault_handler_thread线程中,poll userfaultfd等待事件,之后把一页全是0x66的内容拷贝到page fault发生的那一页:

 

 

我们运行这个程序得到的输出如下:

 

 

我们主线程在执行addr[0]=0x5A5A5A5A的时候,触发了page fault。在fault线程里面,page fault发生后,poll阻塞返回,之后用户通过read()读到了一个uffd_msg的结构体,里面的成员包含了page fault的地址。之后,我们通过UFFDIO_COPY这个ioctl,把内容为0x66的页面拷贝给page fault的页面。

 

所以,最终主线程在执行printf打印的时候,addr[0]里面读到了5A5A5A5A,剩下的addr[1]里面读到了66666666。看到page fault由用户态灵活这么灵活自如地处理,我的小伙伴们都吓尿了。

 

可以看出来:

poll()在等什么,完全被定制化了;

read()能读什么,完全被定制化了;

ioctl()能控制什么,完全被定制化了。

 

我们通过“文件”这个不变的“静”,制造了poll、read、ioctl的灵动自如。兵法有云,以不变应万变,以万变应不变。