goto exit;
if (file->f_path.mnt->mnt_flags & MNT_NOEXEC)
goto exit;
fsnotify_open(file->f_path.dentry);
err = deny_write_access(file);//调用
if (err)
goto exit;
out:
return file;
exit:
fput(file);
return ERR_PTR(err);
}
明显看到了deny_write_access的调用，和预想的完全一致。在open的调用里，应该有get_write_access的调用。在open调用相关的__dentry_open函数中就包含了对该函数的调用。
if (f->f_mode & FMODE_WRITE) {
error = __get_file_write_access(inode, mnt);
if (error)
goto cleanup_file;
if (!special_file(inode->i_mode))
file_take_write(f);
}
其中__get_file_write_access(inode, mnt)封装了get_write_access.
那么内核又是如何保证一个正在被写的文件是不允许被执行的呢?这个同样也很简单，当一个文件已经为write而open时，它对应的inode的i_writecount会变成1，因此在执行execve时同样会调用deny_write_access 中读取到i_writecount>0之后就会返回失败，因此execve也就会失败返回。
这里是写文件与i_writecount相关的场景:
写打开一个文件时，在函数dentry_open中:
if (f->f_mode & FMODE_WRITE) {
error = get_write_access(inode);
if (error)
goto cleanup_file;
}
当然在文件关闭时，会将i_writecount--；关闭时会执行代码:
if (file->f_mode & FMODE_WRITE)
put_write_access(inode);
put_write_access 代码很简单:
static inline void put_write_access(struct inode * inode)
{
atomic_dec(&inode->i_writecount);
}
于是乎自己写了个简单的代码，一个空循环，文件在执行的时候，在bash中，echo 111 >>可执行文件，结果预期之中，返回失败，并提示信息 text file busy.
那么该机制是否同样适用于映射机制呢，在执行可执行文件时，会mmap一些关联的动态链接库，这些动态链接库是否被mmap之后就不允许被写以及正在写时不允许mmap呢?这个是需要考虑的，因为它关系到安全的问题。因为库文件也是可执行的代码，被篡改同样会引起安全问题。
Mmap在调用mmap_region的函数里，有一个相关的检查:
