从监听到监控

Linux的文件事件监听的原理并不复杂，简单说就是当一个应用层的进程操作一个目录或文件时，会触发system call，此时内核的notification子系统可以守在那里，把该进程对文件的操作上报给应用层的监听进程（称为listerner）。

在这个领域，自2001年的2.4版本就引入的dnotify可以说是先驱，然而，它的缺陷实在太多了。正如其名字传达的，只能监控directory，并且它采用的是signal机制来向listener发送通知，因而可以携带的信息很有限。

所以，dnotify基本已经成了「先烈」，一个更优秀的名为"inotify"的监听机制于2005年在2.6.13内核中亮相，它除了可以监控目录，还可以监听普通文件产生的事件。此外，inotify摈弃了signal机制，改为通过event queue的形式向listener上传事件的相关信息。

看起来，inotify已经算是比较完备了，但是它在应用上还是存在诸多限制。其中一个最明显的问题是它只能"notify"，作为listener，只是知道有这个文件事件发生了，最多记录一下，但并不能改变什么（比如被杀毒软件判定为病毒文件，就需要阻止这个操作）。

到了2.6.36内核，fanotify的出现解决了这个痛点，允许listener介入并改变文件事件的行为，才算实现了从“监听”到“监控”的跨越，同时也扩展了其应用的范围。

两个API

fanotify的调用接口是比较简洁的，主要有2个API，但其可携带的参数还是为它的使用增加了很多的灵活性。作为listerner，首先需要通过fanotify_init()函数来设定监控的模式：

#include <fcntl.h>#include <sys/fanotify.h>int fanotify_init(unsigned int flags, unsigned int event_f_flags);

如果"flags"为"FAN_CLASS_CONTENT"，意思是当一个文件的content准备好后，listerner就要介入了，然后给出阻止/放行的决定。为"FAN_CLASS_NOTIF"就是listerner只需要被notify就可以了，类似于「已阅」，但不给出任何的修改意见。

虽然fanotify在内核中并不是作为一个module存在的，也没有对应的设备文件，但从抽象的角度，你完全可以把它视作一个特殊的文件，而"fanotify_init"就是去"open"这个文件，因此这里的"event_f_flags" 其实和VFS中open()系统调用的"flags" 参数差不多（比如" O_RDONLY"），这也是为什么需要包含"fcntl.h"头文件的原因。

同open()一样，该函数返回的也是代表fanotify这个特殊文件的file descriptor，获得了fd后，就可以利用fanotify_mark()来展开具体的配置了：

int fanotify_mark(int fanotify_fd, unsigned int flags,                  uint64_t mask, int dirfd, const char *pathname);

文件事件的监控大致包括两个维度：对哪些文件产生的事件感兴趣，以及对这些文件的哪些事件感兴趣。"flags" 就是用来增加/删除感兴趣的文件列表（通过"FAN_MARK_ADD"/"FAN_MARK_REMOVE"等），而"mask" 就是用来设置感兴趣的事件列表，比如"FAN_OPEN"就是当文件被打开时，产生一个事件给listener。

至于"dirfd" 和"pathname"，则是用来给出文件路径的，比如"AT_FDCWD"就表示从当前路径（Current Working Directory）开始解析。

一个mark针对一个文件，那它是怎么和内核中表示文件的数据结构关联起来的呢？文件的唯一标识是inode，mark通过一个"fsnotify_mark_connector"类型的指针，指向了inode结构体中对应的元素（至于这里为什么是叫"fsnotify"而不是"fanotify"，将在本文后半部分给出答案）：

熟悉epoll的同学可能已经发现，fanotify_init()其实和epoll_create()挺像的，都是用来监听文件，而本身的instance也作为一个文件，有对应的file descriptor供应用程序操作。fanotify_mark()则可类比于epoll_ctl()，都是用来增删和修改事件列表的。

int epoll_create(int size);int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

不过，fanotify并没有epoll_wait()这样的轮询机制，不能直接让listerner收到事件，所以在具体的使用上，fanotify和poll/epoll是层级的关系：

那为什么不直接只用epoll呢？这还得从fanotify的原理说起。先来看下对于一个被监控文件进行open操作时，fanotify是怎么发挥作用的：

在do_dentry_open()之前，都是VFS的标准调用路径，而到了security_file_open()这里，已经准备好hook，在此潜伏已久的各路人马就开始出手了：

int security_file_open(struct file *file){    int ret = call_int_hook(file_open, 0, file);    if (ret)        return ret;		    return fsnotify_perm(file, MAY_OPEN);}

这些人马主要来自LSM(Linux Security Module)，比如著名的SELinux（参考这篇文章）：

call_int_hook -->hlist_for_each_entry(P, &security_hook_heads.FUNC, list) {     RC = P->hook.FUNC(__VA_ARGS__);		    if (RC != 0)				        break;}

走到fsnotify_perm()这里，终于轮到前面已经露过一回脸的fsnotify了。从dnotify到inoitfy，再到fanotify，缺陷和限制逐渐减少，但这不是一个迭代的关系，它们仨的代码目前都存在于"/fs/notify"目录。

同时，由于机制的相似性，它们存在很多共通之处，将这些共通之处提取出来，就成了fsnotify。fsnotify作为后端，负责接收文件事件，它被作为前端、和listener直接交互的dnotify, inotify和fanotify所共享。

每一个前端instance被抽象为一个"group"（在代码中由"fsnotify_group"结构体表示），每个group都有自己的notification queue（以下简称"nq"），用于向listener传递事件。

从效率的角度，fsnotify不会把收到的事件依次放到每个group的"nq"上，而是只维护一个event queue，根据各个group配置的mask，在其对应的"nq"里存放指针，指向event queue中感兴趣的事件。

那fsnotify具体是如何将事件送到fanotify这个group，fanotify又是怎样和应用层的listener打交道的呢，请看下文分解。