VFS与Netlink结合：构建内核态到用户态的数据通道实战

1. 为什么把VFS和Netlink放在一起做实验

这个题目乍看有点“缝合怪”——VFS（虚拟文件系统）是Linux内核里管理一切文件操作的抽象层，Netlink是内核与用户空间通信的Socket机制，两者属于不同子系统。但如果你做过系统监控、容器隔离或者内核态文件系统相关的开发，一定遇到过这样的需求：用户态程序需要查询当前系统挂载了哪些文件系统、某个挂载点的类型和统计信息、甚至想主动触发一次sync写回。这时候，VFS是数据的源头，Netlink是把数据从内核“递出来”的通道，两者配合刚好形成一个完整的内核态能力闭环。

我在做这个实验之前，处理这类需求通常是两个选择：要么用/proc/mounts和/proc/self/mountstats这类现成节点去读，要么写一个ioctl打到设备驱动里。前者简单但信息量受限，你拿不到内核struct super_block里的很多内部状态；后者的扩展性和通用性都不好，每加一个功能就要改驱动接口。用Netlink做通道，用VFS的挂载点遍历和超级块信息做数据源，相当于在用户态和内核态之间建立一条可控的“私有链路”，既能拿到VFS层的原生数据，又不用污染现有的系统调用接口。

适合谁看？如果你正在做系统监控Agent、容器运行时、分布式存储的客户端组件，或者纯粹想深入理解Linux内核的VFS和Socket通信机制，这篇文章的实战代码可以直接改吧改吧拿过去用。

2. VFS层的核心机制：先搞清楚数据在哪

很多人一听到“虚拟文件系统”就头大，觉得它是个很玄的抽象。实际上VFS就是一个巨大的“翻译层”，它定义了一组通用对象和操作函数集，让上层应用不用关心底层块设备、磁盘格式甚至网络文件系统之间的差异。

2.1 四个核心对象：超级块、inode、dentry、file

VFS的核心建模是四个结构体，理解了这个四件套，后面写代码找数据就不会迷路：

• super_block：代表一个已挂载的文件系统实例，包含文件系统类型、挂载标志、设备信息、统计字段等。每个挂载点对应一个超级块。
• inode：代表磁盘上的一个文件（或目录）的元数据，包括权限、大小、时间戳、数据块位置等。它是VFS中最核心的“实体”。
• dentry：目录项缓存，代表路径中的一个分量。比如/mnt/data/file会分解成/, mnt, data, file四个dentry。它的作用是加速路径解析。
• file：代表进程打开的一个文件描述符对应的内核对象，保存当前读写位置、文件操作函数指针等。

这个四件套的关系，可以类比成一个图书馆的运营体系：超级块是“图书馆总馆”（每个分馆一个），inode是“书架上的每一本书”（书的目录信息），dentry是“图书馆的检索卡片”（帮你在总目录里快速找到书在哪个分馆哪个架子），file是“你手上正打开的那本书”（记录你现在读到第几页）。

2.2 路径解析与dcache加速

当你在用户态执行open("/mnt/data/file", O_RDONLY)时，内核会走一遍pathwalk流程：从当前进程的fs_struct找到根目录和当前工作目录的dentry，然后逐级查找路径分量。这个查找过程优先查dcache（目录项缓存），缓存没命中才触发底层文件系统的lookup操作从磁盘读取。

dcache是VFS性能的生命线。如果不缓存dentry，每次open一个深路径文件都要做多次磁盘I/O，系统早就卡死了。这也是为什么stat、ls这类操作第一次慢、第二次快的原因——第一次的dentry和inode已经被缓存进内存了。

2.3 遍历挂载点的正确姿势

我们要从VFS拿数据，最主要的是遍历当前命名空间的所有挂载点。内核里有一个全局链表mount_hashtable和list_head类型的mount_list，但在现代内核（4.x以上）中，更推荐通过namespace_lock和list_for_each_entry遍历当前命名空间的挂载点。

实际操作中，我是在内核模块里这样做的：

c复制#include <linux/fs.h>
#include <linux/mount.h>
#include <linux/namei.h>

static void walk_mounts(void)
{
    struct path path;
    struct mount *mnt, *tmp;
    struct vfsmount *vfsmnt;
    
    namespace_lock();
    list_for_each_entry(mnt, &current->nsproxy->mnt_ns->list, mnt_list) {
        vfsmnt = &mnt->mnt;
        // vfsmnt->mnt_sb 指向超级块
        // vfsmnt->mnt_root 是挂载点的根dentry
        // mnt->mnt_mountpoint 是挂载点位置的dentry
        printk("mount: %s %s\n", 
               vfsmnt->mnt_sb->s_id, 
               d_path(&mnt->mnt_mountpoint, buf, PAGE_SIZE));
    }
    namespace_unlock();
}

这里有个细节要注意：d_path()函数必须在持有锁的情况下调用，而且不能睡眠。因为d_path会遍历dentry的父链，如果底层dentry并发变化，可能导致路径信息错误。namespace_lock()保护的是挂载命名空间的链表，不是dentry引用计数，所以用完之后要及时解锁。

2.4 从超级块拿文件系统统计信息

拿struct super_block的字段是重头戏。常用的几个：

• s_type->name：文件系统类型名（如ext4、xfs）
• s_id：设备标识（如sda1）
• s_flags：挂载标志（MS_RDONLY等）
• s_magic：文件系统魔数
• s_count：引用计数
• s_wb_err：写回错误状态
• s_dirty：是否包含脏inode

如果还想知道某个挂载点的读写字节数、文件数等，需要读取sb->s_op里导出的统计接口，或者从diskstats获取底层块设备的信息。这里给出一个简单的查询函数：

c复制static void report_super_block(struct super_block *sb)
{
    struct dentry *root = sb->s_root;
    
    pr_info("device: %s\n", sb->s_id);
    pr_info("fs type: %s\n", sb->s_type->name);
    pr_info("magic: 0x%lx\n", (unsigned long)sb->s_magic);
    
    if (root && root->d_inode) {
        pr_info("root inode: %lu\n", root->d_inode->i_ino);
        pr_info("size: %lld\n", root->d_inode->i_size);
    }
}

注意sb->s_root可能为NULL，比如文件系统正在被卸载或挂载未完成，所以必须有root && root->d_inode的判断，否则内核直接解引用空指针，模块崩溃不说，可能直接带崩整个系统。

3. Netlink编程：内核态与用户态的“消息管道”

Netlink的设计初衷是提供一种灵活、异步、支持多播的内核-用户空间通信机制。它比/proc节点灵活，比ioctl通用，比syscall扩展性好。尤其是当你需要“内核主动向用户态推送事件”的场景——比如挂载事件变更、文件系统错误告警——Netlink几乎是唯一合理的选择。

3.1 Netlink的地址与协议格式

Netlink编程涉及几个核心数据结构：

c复制struct sockaddr_nl {
    __kernel_sa_family_t nl_family;  // AF_NETLINK
    unsigned short nl_pad;
    __u32 nl_pid;        // 端口号，内核为0，用户进程为进程PID
    __u32 nl_groups;     // 多播组掩码
};

struct nlmsghdr {
    __u32 nlmsg_len;   // 整个消息长度，包括头部
    __u16 nlmsg_type;  // 消息类型
    __u16 nlmsg_flags; // 标志
    __u32 nlmsg_seq;   // 序列号
    __u32 nlmsg_pid;   // 发送方PID
};

需要明确的是，nl_pid在现代Linux中并不一定等于PID，它可以是任意非零值，只要在同一Netlink协议族下唯一即可。用户态一般直接用getpid()，但如果一个进程内多个线程都创建Netlink socket，需要各自分配不同的nl_pid以避免冲突，可以用“线程号+偏移”的方式。

3.2 为什么选Netlink而不是procfs/ioctl/syscall

表格对比一下几种内核-用户通信方式的适用场景：

一句话总结：Netlink就是“内核态的UDP socket”，它自带消息边界，发送方write一个消息，接收方read到的是一个完整消息，不用自己处理粘包拆包（底层有缓冲管理）。

3.3 内核态Netlink socket的创建与发送

在内核模块里创建Netlink socket需要用到netlink_kernel_create接口，老内核和新内核的API差异较大。我拿Linux 5.10的API为例：

c复制#include <net/netlink.h>
#include <net/sock.h>

static struct sock *nl_sk;

static void nl_recv_msg(struct sk_buff *skb)
{
    struct nlmsghdr *nlh = nlmsg_hdr(skb);
    // 根据nlh->nlmsg_type和nlmsg_len处理消息
}

static int __init netlink_demo_init(void)
{
    struct netlink_kernel_cfg cfg = {
        .input = nl_recv_msg,
    };
    
    nl_sk = netlink_kernel_create(&init_net, NETLINK_USERSOCK, &cfg);
    if (!nl_sk) {
        pr_err("netlink_kernel_create failed\n");
        return -ENOMEM;
    }
    return 0;
}

NETLINK_USERSOCK是给用户自定义使用的协议号，范围在NETLINK_GENERIC之后。内核态发送消息时，需要构造sk_buff并填充nlmsghdr：

c复制static int send_msg_to_user(u32 pid, int msg_type, void *data, size_t len)
{
    struct sk_buff *skb;
    struct nlmsghdr *nlh;
    int size = NLMSG_SPACE(len);
    
    skb = alloc_skb(size, GFP_KERNEL);
    if (!skb)
        return -ENOMEM;
    
    nlh = nlmsg_put(skb, 0, 0, msg_type, len, 0);
    if (!nlh) {
        kfree_skb(skb);
        return -EMSGSIZE;
    }
    
    memcpy(NLMSG_DATA(nlh), data, len);
    
    netlink_unicast(nl_sk, skb, pid, MSG_DONTWAIT);
    return 0;
}

这里有个关键点：NETLINK_CB(skb).portid会决定消息的源地址，所以一般需要在alloc_skb后设置NETLINK_CB(skb).portid = 0（代表来自内核）。

3.4 用户态Netlink编程：create、bind、recv

用户态就比较简单了，直接和标准socket编程一样：

c复制#include <sys/socket.h>
#include <linux/netlink.h>

int main(void)
{
    int sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_USERSOCK);
    struct sockaddr_nl addr = {0};
    
    addr.nl_family = AF_NETLINK;
    addr.nl_pid = getpid();
    addr.nl_groups = 0;
    
    if (bind(sock, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("bind");
        return -1;
    }
    
    char buf[8192];
    struct iovec iov = { buf, sizeof(buf) };
    struct msghdr msg = {0};
    
    // 发送请求，通知内核准备上报
    struct nlmsghdr *nlh = (struct nlmsghdr *)buf;
    nlh->nlmsg_len = NLMSG_LENGTH(0);
    nlh->nlmsg_type = NLMSG_DONE;
    nlh->nlmsg_flags = 0;
    nlh->nlmsg_seq = 1;
    nlh->nlmsg_pid = getpid();
    
    struct sockaddr_nl kernel_addr = {0};
    kernel_addr.nl_family = AF_NETLINK;
    kernel_addr.nl_pid = 0;
    
    sendmsg(sock, &(struct msg) { .msg_name = &kernel_addr, ... }, 0);
    
    // 接收内核消息
    recvmsg(sock, &msg, 0);
    ...
}

注意recvmsg的msg.msg_name传入struct sockaddr_nl并设置msg_namelen，这样才能拿到发送端地址（内核的pid=0）。如果不关心发送方，可以传NULL。

4. 实战：从VFS拿挂载点信息并通过Netlink上报

下面我给出一个完整可编译的内核模块和用户态程序，组合起来能实现：用户态发一个“查询请求”，内核模块遍历当前命名空间的所有挂载点，把每个挂载点的类型、设备、路径信息通过Netlink发送回用户态。

4.1 内核模块完整代码

c复制// vfs_netlink_mod.c
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/fs.h>
#include <linux/mount.h>
#include <linux/netlink.h>
#include <linux/skbuff.h>
#include <net/sock.h>

#define NETLINK_VFS 31
#define NL_MSG_QUERY_MOUNTS 0x01
#define NL_MSG_MOUNT_INFO   0x02

struct mount_info {
    char fs_type[32];
    char device[32];
    char mount_point[512];
    unsigned long magic;
    unsigned long flags;
};

static struct sock *nl_sk = NULL;

static void send_mount_info(u32 pid, struct mount_info *info)
{
    struct sk_buff *skb;
    struct nlmsghdr *nlh;
    int size = NLMSG_SPACE(sizeof(*info));
    
    skb = alloc_skb(size, GFP_KERNEL);
    if (!skb) {
        pr_err("alloc_skb failed\n");
        return;
    }
    
    nlh = nlmsg_put(skb, 0, 0, NL_MSG_MOUNT_INFO, sizeof(*info), 0);
    memcpy(NLMSG_DATA(nlh), info, sizeof(*info));
    NETLINK_CB(skb).portid = 0;
    NETLINK_CB(skb).dst_group = 0;
    
    if (netlink_unicast(nl_sk, skb, pid, MSG_DONTWAIT) < 0) {
        pr_err("netlink_unicast failed\n");
    }
}

static void dump_mounts_to_user(u32 pid)
{
    struct mount *mnt;
    struct vfsmount *vfsmnt;
    struct mount_info info;
    char *path_buf;
    char *path;
    
    path_buf = (char *)__get_free_page(GFP_KERNEL);
    if (!path_buf)
        return;
    
    namespace_lock();
    list_for_each_entry(mnt, &current->nsproxy->mnt_ns->list, mnt_list) {
        vfsmnt = &mnt->mnt;
        memset(&info, 0, sizeof(info));
        
        strlcpy(info.fs_type, vfsmnt->mnt_sb->s_type->name, sizeof(info.fs_type));
        strlcpy(info.device, vfsmnt->mnt_sb->s_id, sizeof(info.device));
        info.magic = vfsmnt->mnt_sb->s_magic;
        info.flags = vfsmnt->mnt_sb->s_flags;
        
        path = d_path(&mnt->mnt_mountpoint, path_buf, PAGE_SIZE);
        if (!IS_ERR(path))
            strlcpy(info.mount_point, path, sizeof(info.mount_point));
        
        send_mount_info(pid, &info);
    }
    namespace_unlock();
    
    free_page((unsigned long)path_buf);
}

static void nl_recv_msg(struct sk_buff *skb)
{
    struct nlmsghdr *nlh = nlmsg_hdr(skb);
    u32 pid = NETLINK_CB(skb).portid;
    
    if (nlh->nlmsg_type == NL_MSG_QUERY_MOUNTS) {
        dump_mounts_to_user(pid);
    }
}

static int __init vfs_netlink_init(void)
{
    struct netlink_kernel_cfg cfg = {
        .input = nl_recv_msg,
    };
    
    nl_sk = netlink_kernel_create(&init_net, NETLINK_VFS, &cfg);
    if (!nl_sk) {
        pr_err("Failed to create netlink socket\n");
        return -ENOMEM;
    }
    pr_info("VFS netlink module loaded, protocol %d\n", NETLINK_VFS);
    return 0;
}

static void __exit vfs_netlink_exit(void)
{
    if (nl_sk) {
        netlink_kernel_release(nl_sk);
        nl_sk = NULL;
    }
    pr_info("VFS netlink module unloaded\n");
}

module_init(vfs_netlink_init);
module_exit(vfs_netlink_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("VFS mount info via netlink demo");

有几个点我实际操作中吃过亏：

• current宏在中断上下文或持有某些锁时不能安全使用。在nl_recv_msg回调里，current指向当前合法的进程上下文，可以直接用，但如果代码路径变成了定时器回调或workqueue上下文，要小心。这个demo在正常进程触发下没问题。
• dump_mounts_to_user里我在namespace_lock()保护下直接调用了netlink_unicast。这是可行的，因为netlink_unicast在MSG_DONTWAIT下不会睡眠，但如果有大量挂载点，每个挂载点都发送一个消息会频繁分配skb，性能上不划算。更优的做法是批量打包成多个消息放进一个skb，用nlmsg_put连续填充，最后一次性发出。
• __get_free_page分配的是整页物理连续内存（4KB），在持有命名空间锁时分配内存是高危操作。如果系统内存压力大，GFP_KERNEL分配会触发回收和睡眠，但namespace_lock是自旋锁类型？实际上namespace_lock()是mutex_lock，允许睡眠，所以这里其实没问题，但需要理解自己拿的锁是哪种类型。这里用的是namespace_lock()，定义在pnode.c里，是可以睡眠的信号量锁。

4.2 内核模块的Makefile

makefile复制obj-m += vfs_netlink_mod.o

KERNEL_DIR ?= /lib/modules/$(shell uname -r)/build

all:
	$(MAKE) -C $(KERNEL_DIR) M=$(PWD) modules

clean:
	$(MAKE) -C $(KERNEL_DIR) M=$(PWD) clean

编译出来后insmod vfs_netlink_mod.ko。

4.3 用户态程序

c复制// vfs_netlink_user.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <linux/netlink.h>
#include <linux/types.h>

#define NETLINK_VFS 31
#define NL_MSG_QUERY_MOUNTS 0x01
#define NL_MSG_MOUNT_INFO   0x02

struct mount_info {
    char fs_type[32];
    char device[32];
    char mount_point[512];
    unsigned long magic;
    unsigned long flags;
};

static int nl_fd;

static void send_query(void)
{
    char buf[64] = {0};
    struct nlmsghdr *nlh = (struct nlmsghdr *)buf;
    struct sockaddr_nl kernel = {0};
    struct iovec iov = { buf, sizeof(buf) };
    struct msghdr msg = {0};
    
    nlh->nlmsg_len = NLMSG_LENGTH(0);
    nlh->nlmsg_type = NL_MSG_QUERY_MOUNTS;
    nlh->nlmsg_flags = 0;
    nlh->nlmsg_seq = 1;
    nlh->nlmsg_pid = getpid();
    
    kernel.nl_family = AF_NETLINK;
    kernel.nl_pid = 0;
    
    msg.msg_name = &kernel;
    msg.msg_namelen = sizeof(kernel);
    msg.msg_iov = &iov;
    msg.msg_iovlen = 1;
    
    if (sendmsg(nl_fd, &msg, 0) < 0) {
        perror("sendmsg");
        exit(1);
    }
}

static void recv_mounts(void)
{
    char buf[8192];
    struct iovec iov = { buf, sizeof(buf) };
    struct sockaddr_nl from;
    struct msghdr msg;
    int ret;
    
    for (;;) {
        memset(&msg, 0, sizeof(msg));
        msg.msg_name = &from;
        msg.msg_namelen = sizeof(from);
        msg.msg_iov = &iov;
        msg.msg_iovlen = 1;
        
        ret = recvmsg(nl_fd, &msg, 0);
        if (ret < 0) {
            perror("recvmsg");
            break;
        }
        
        struct nlmsghdr *nlh = (struct nlmsghdr *)buf;
        if (nlh->nlmsg_type == NL_MSG_MOUNT_INFO) {
            struct mount_info *info = (struct mount_info *)NLMSG_DATA(nlh);
            printf("%-10s %-12s %-40s magic=0x%lx flags=0x%lx\n",
                   info->fs_type, info->device, info->mount_point,
                   info->magic, info->flags);
        } else {
            // 未知消息，继续
        }
    }
}

int main(void)
{
    nl_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_VFS);
    if (nl_fd < 0) {
        perror("socket");
        return 1;
    }
    
    struct sockaddr_nl addr = {0};
    addr.nl_family = AF_NETLINK;
    addr.nl_pid = getpid();
    addr.nl_groups = 0;
    
    if (bind(nl_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("bind");
        return 1;
    }
    
    send_query();
    recv_mounts();
    
    close(nl_fd);
    return 0;
}

编译、运行：

bash复制gcc -o vfs_netlink_user vfs_netlink_user.c
sudo insmod vfs_netlink_mod.ko
./vfs_netlink_user

正常输出会打印所有挂载点。我这里测试的典型输出：

code复制ext4       sda2       /                          magic=0xef53 flags=0x1000
proc       proc       /proc                      magic=0x9fa0 flags=0x1001
sysfs      sysfs      /sys                       magic=0x62656572 flags=0x1001
tmpfs      tmpfs      /run                       magic=0x01021994 flags=0x1240
overlay    overlay    /docker/overlay2/...       magic=0x794c7630 flags=0x1000

注意/proc的device显示为proc，不是块设备，这符合预期。flags=0x1000是MS_RELATIME等标志的组合值，想查具体含义可以对比<linux/fs.h>里的MS_*定义。

5. 踩坑记录：从内核态到用户态的典型问题排除

实话实说，这个Demo第一次跑通耗了我不少时间，踩的坑也很有代表性，给各位列几个印象最深的。

5.1 NETLINK_CB(skb).portid不设置导致的“消息来源成谜”

如果你在内核态发送消息前不设置NETLINK_CB(skb).portid，它的初始值可能是skb分配时的残留值，或者默认的0（代表内核）。但在某些内核版本里，这个值会继承自alloc_skb的某个字段，导致用户态接到的消息nlmsg_pid不是0，看起来就像“不知道谁发的”。用户态一般通过recvmsg的from.nl_pid判断消息是否来自内核，如果不为0，可能直接丢弃消息。所以内核发送侧务必显式设置：

c复制NETLINK_CB(skb).portid = 0;
NETLINK_CB(skb).dst_group = 0;

5.2 NLMSG_SPACE还是NLMSG_LENGTH？计算不当导致缓冲区溢出

在构造发送缓冲区时，NLMSG_LENGTH(len)返回的是“消息头长度 + 数据长度”，而NLMSG_SPACE(len)返回的是NLMSG_LENGTH(len)向上对齐到4字节后的总长度。alloc_skb分配的是整个NLMSG_SPACE的大小，但nlmsg_put内部会做校验：如果len太大导致超出skb尾部，会返回NULL。实际经验是：算发送缓冲一律用NLMSG_SPACE，算消息内偏移用NLMSG_LENGTH。很多新手混用这两个宏，导致分配4096字节缓冲区，实际只填充了4092字节的数据，最后nlmsg_len写的是4096，接收端解包越界。

5.3 内核态调用d_path必须持有锁且不能中断上下文

d_path需要遍历dentry的父链，如果dentry正在被并发改名或删除，读到的路径可能是错的，甚至引发悬空指针。所以正确姿势是在持有namespace_lock或rename_lock的情况下调用，并且结果要strlcpy到自己的缓冲区之后再释放锁。永远不要想着“先临时存个指针，等会儿再用”，因为dentry的生命周期可能在你释放锁后立刻结束。

另外，d_path在中断上下文或软中断上下文不能调用，因为它可能睡眠。这个Demo里用的是netlink_kernel_create的input回调，运行在进程上下文（如果是sendmsg触发，就对应发送线程），所以安全。

5.4 多挂载点时缓存与发送策略

如果系统里有几百个挂载点（容器宿主机很常见），一个一个发Netlink消息会产生大量小skb，内核内存分配压力和网络栈开销都会变大。优化手法有两个：一是合并成一个大skb，一个nlmsghdr后面跟一串mount_info，接收端循环解析；二是先写在seq_file或relayfs等批量接口里，再用Netlink只发“就绪通知”。第一种方案对数据量在几KB的挂载点列表完全够用，代码改动也不大。

5.5 模块卸载时的竞态

模块卸载时，如果还有用户态socket连接在收消息，而模块已经在netlink_kernel_release后释放了Netlink socket，用户态可能收到ECONNRESET错误。处理方式是先获取nl_sk上的用户引用，如netlink_has_listeners检查是否有监听者，或者简单粗暴地在模块退出时主动向所有绑定进程发一个NLMSG_ERROR类型消息通知关闭。我一般用sock_netlink_getsockbyportid查一下有没有活跃对端：

c复制static void notify_clients_exit(void)
{
    struct sock *sk = netlink_getsockbyportid(nl_sk, pid);
    if (sk) {
        // 发送退出消息
        sock_put(sk);
    }
}

不过这需要维护当前活动用户PID列表，Demo里先不展开，生产环境值得做。

5.6 一个隐藏的坑：命名空间

初版Demo里我直接用了current->nsproxy->mnt_ns。这个做法在“当前进程所在的命名空间”下是有效的。但如果你想让模块在所有命名空间下都能收到请求、并只报告请求者自己命名空间的挂载点，这种写法是正确的。如果你错误地用init_mnt_ns（初始化命名空间），在容器内触发查询时，拿到的是宿主机的挂载列表，而不是容器内的，数据就会“串台”。容器环境下做监控，这是最容易踩的坑。

6. 扩展思路：除了挂载点，还能用这种架构做什么

VFS和Netlink一旦串起来，能做的事情远不止打印挂载列表。

6.1 实时跟踪挂载/卸载事件

内核的fsnotify子系统配合mount事件的钩子（如fsnotify_vfsmount_tree或直接监听sb->s_event），可以在挂载点和文件系统注册/注销事件发生的第一时间通过Netlink推送到监控Agent。Netlink天然支持多播，一个用户态Agent可以订阅多组事件，不用像/proc那样轮询。

6.2 主动触发sync并获取写回状态

sync是一类需要权限且可能耗时的操作。用Netlink封装一个“同步请求”接口，用户态发送指定挂载点的sync请求，内核态遍历其超级块并调用sync_filesystem或writeback_inodes_sb，完成后回传错误码。这就比用户在shell里执行sync; echo $?要精细得多，可以针对单文件系统做细粒度写回。

6.3 inotify事件的用户态转发

虽然inotify本身已经是内核-用户态机制，但它在容器场景下有局限：inotify的watch对象是具体文件路径，无法直接监控整个挂载点的创建/删除。通过VFS层的dentry操作钩子（d_lookup、d_instantiate等）捕获目录变更，再走Netlink推送，可以实现一个“目录结构变更审计”工具，这在安全审计、容器逃逸检测里是有实际价值的。

6.4 自定义文件系统状态查询接口

如果你在开发FUSE或内核态文件系统，经常需要暴露内部统计信息（缓存命中率、读写延迟分位数、并发数）。Netlink协议的定义完全由你掌控，可以设计一套类似RPC风格的请求-响应模型，协议号用NETLINK_GENERIC或者自己申请一个。扩展性比在/sys下造一堆属性文件好得多。

7. 实操经验与建议

折腾完这个项目，我对VFS和Netlink的理解有了质的变化。几点建议供各位参考：

第一，先学会看内核源码再动手。VFS相关的fs/namespace.c、fs/dcache.c、fs/super.c是我们这个Demo的“参考手册”，遇到不理解的结构体，直接grep -rn "struct mount " /usr/src/linux-headers-$(uname -r)/include/linux/mount.h。Netlink部分重点看include/net/netlink.h和net/netlink/af_netlink.c。内核代码虽然多，但结构清晰，读一遍比看十篇博客都管用。

第二，编写内核模块时，锁和内存分配是第一位的事。很多初学者在写VFS相关代码时拿到一个dentry指针就存起来，等异步回调再用。这是典型的UAF（Use-After-Free）隐患。正确做法是：要么在持有引用计数的情况下传递指针，要么把需要的数据拷到自己的内存里。我自己的习惯是“能拷不传、能不用指针就不用指针”，减少内核态异步逻辑的复杂度。

第三，用户态Netlink程序最好用非阻塞+epoll模型。如果Agent要同时监听文件系统事件、网络事件和多路信号，不能让一个recvmsg阻塞了所有事件循环。用epoll监听Netlink socket的EPOLLIN，配合超时和重连机制，才是生产级写法。我在Demo里用了阻塞recvmsg是为了演示简单，实际工程要改成事件驱动。

第四，模块开发时的调试技巧。内核模块打印消息用pr_info、pr_err加模块名前缀，然后dmesg -wT实时跟踪。如果遇到crash，dmesg里的oops信息会指示具体指令地址和寄存器，配合objdump -d vfs_netlink_mod.ko和addr2line可以快速定位。这次开发中我遇到过两次oops，都是d_path未加锁导致的问题，从此养成了“从锁里能拿到路径就绝不拖出锁外再处理”的习惯。

最后说一个体会：VFS和Netlink这两个子系统单看都不算难，难点在于它们的组合场景非常考验对内核上下文、锁和执行路径的理解。当你把一套数据从VFS摘出来，用Netlink送出去，实际上是在编写一条“内核数据通路”。这条通路的每一环——数据源、锁保护、缓冲管理、消息协议、用户态解析——都需要想清楚数据流和生命周期。把这条通路跑通，对你理解整个Linux内核的IO栈和进程上下文模型，会有事半功倍的效果。