c - Linux 内核 filp_open 失败并显示 NOENT

Question

更新 :在@kisch 的出色答案的延续中，我阅读了有关softirq 上下文的信息，并且似乎(出于非常合理的原因)无法从该上下文中访问用户模式。我认为这确实是它失败的原因。
目前在我处理用户空间文件的内核模块上工作。我知道这被认为是一种不好的做法，但我仍然需要。
该模块使用 netfilter 放置一个钩子(Hook)来捕获系统中的每个传出数据包，并且在调用该钩子(Hook)时 - 它调用 filp_open .
巫毒从这里开始。
当我从环回发送 ping 时，一切正常，在这种情况下，文件 (/etc/fstab) 已成功打开。
当我从家里的不同 IP ping 机器时，filp_open失败 ENOENT .
为了弄清楚它实际失败的地方，我在 QEMU 仿真上运行了该模块，成功地重现了奇怪的行为。显然，它在内核内部函数中失败了 do_last ，在下一个代码中(取自 fs/namei.c):

if (unlikely(d_is_negative(path.dentry))) {
        path_to_nameidata(&path, nd);
        return -ENOENT;
    }

我完全不知道是什么使它失败，因为文件一直存在。
有人有什么想法吗？
这是代码中失败的部分:

unsigned int nf_sendfile_hook(void *priv,
                              struct sk_buff *skb,
                              const struct nf_hook_state *state)
{    
    if (NULL == g_get_payload_func) {
        // as long as we don't have a way to get our payloads, we don't 
        // have much to do.
        return NF_ACCEPT;
    }

    struct file *filp;
    filp = filp_open("/etc/fstab", O_RDONLY, 0);
    if (IS_ERR(filp)) {
        printk(KERN_ERR "%p\n", filp);
        return NF_ACCEPT;
    }
    
    ...
}

预先感谢。

Answer 1

我需要更多细节才能确定。
你到底在哪里上钩？
很可能，不同的行为是由内核调用钩子(Hook)函数的不同上下文引起的。
当你

send a ping from the loopback,

您有一个用户空间进程发出 sendmsg() 系统调用。
内核在附加到该进程的用户上下文中启动一个调用链。
在将数据包放入队列以进行进一步的分离处理之前，可能会直接在该调用链中调用 netfilter Hook 。
当你

ping the machine from a different IP in my house,

你有一个从 NET_RX_SOFTIRQ 的 Soft-IRQ 上下文开始的调用链, 从 net_rx_action() 开始.该调用链将传入数据包分类为 ICMP，将其传递给内部 ICMP 接收例程，该例程直接发送 ping 回复数据包，然后可能调用 netfilter Hook 。
Soft-IRQ 上下文与任何用户空间进程无关。
现在取决于您的内核设置，文件系统查找代码完全有可能取决于用户上下文中存在的信息，以决定访问限制。您可能有挂载命名空间，因此如果没有用户上下文的进程 ID，甚至可能不会挂载/etc 文件系统，这将解释 ENOENT。
文件系统查找代码也很可能需要调用一些需要 schedule() 的操作。 ，即阻塞直到一个耗时的操作完成(例如在文件系统的底层设备的 block 中分页以进行查找)。这在 SoftIRQ 上下文中不起作用。
这还不是一个完整的答案，太多的“可能”，但我很确定这是在哪里找到它的正确方向。