Linux内核系统调用中写入并执行可执行文件的writecount异常问题

我来帮你拆解这个内核态文件操作的坑——你遇到的核心问题是：调用filp_close后，目标文件的inode写计数（writecount）没及时降到0，导致kernel_execve执行时判定文件还在被写占用，直接阻止了执行。而你用put_write_access临时解决了执行问题，但破坏了写计数的平衡，自然导致后续没法修改文件。

问题根源 #

内核态的文件操作逻辑和用户态不一样：filp_close虽然关闭了文件指针，但inode的写访问引用可能因为内核的延迟释放机制、上下文缓存等原因，没有被立即清理。这时候kernel_execve检查文件状态时，看到writecount>0，就会认为文件处于不可执行的写状态。

而额外调用put_write_access会让计数提前降到0，但每一次get_write_access都需要对应一次put_write_access，多调用一次会让计数失衡——后续修改文件时，内核尝试获取写权限就会失败。

正确的解决方案 #

要同时搞定执行和后续修改的问题，得确保文件关闭后inode的写引用被正确释放，还要同步磁盘数据和inode状态。调整你的代码如下：

struct file *destfile;
struct inode *inode;
int ret;

// 打开/创建目标文件
destfile = filp_open(destfilename, O_WRONLY | O_TRUNC | O_CREAT, 0755);
if (IS_ERR(destfile)) {
    pr_err("Failed to open file: %s\n", destfilename);
    if (!IS_ERR(sourcefile)) {
        filp_close(sourcefile, NULL);
    }
    return PTR_ERR(destfile);
}

// 这里写入你的文件内容逻辑
// ... 你的写入代码 ...

// 同步文件数据到磁盘，强制更新inode状态
ret = vfs_fsync(destfile, 0);
if (ret != 0) {
    pr_err("Failed to sync file: %s\n", destfilename);
    filp_close(destfile, NULL);
    if (!IS_ERR(sourcefile)) {
        filp_close(sourcefile, NULL);
    }
    return ret;
}

// 关闭文件
filp_close(destfile, NULL);

// 手动检查并清理inode的写计数（仅在必要时）
inode = iget(destfile->f_path.dentry->d_sb, destfile->f_path.dentry->d_inode->i_ino);
if (inode) {
    if (inode->i_writecount > 0) {
        put_write_access(inode);
    }
    iput(inode);
}

// 执行目标文件
kernel_execve(destfilename, (char *const[]){destfilename, NULL}, (char *const[]){NULL});

关键细节说明 #

• vfs_fsync的作用：强制把文件的脏数据和inode元数据刷到磁盘，让内核及时更新inode的状态，包括初步清理写计数。
• inode的手动处理：用iget获取inode，先检查i_writecount，只有当计数确实大于0时才调用put_write_access，避免破坏计数平衡。处理完用iput释放inode引用，保证后续修改文件时权限正常。
• 增强错误处理：每一步失败时都确保已打开的文件被关闭，避免内核资源泄漏。

替代小技巧 #

如果你的内核上下文允许，也可以试试用sys_open、sys_write、sys_close这些用户态系统调用的内核包装函数来完成文件操作——它们的上下文管理更贴近用户态，大概率能自动避免writecount残留的问题，不过要注意权限和上下文的正确性。

内容的提问来源于stack exchange，提问作者Viorel Preoteasa