关于Linux文件系统的几点注意事项
扫描二维码
随时随地手机看文章
做内核开发的朋友，可能对下面的代码都很眼熟。
1. static const struct file_operations xxx_fops = {
2. .owner = THIS_MODULE,
3. .llseek = no_llseek,
4. .write = xxx_write,
5. .unlocked_ioctl = xxx_ioctl,
6. .open = xxx_open,
7. .release = xxx_release,
8. };
一般我们在xxx_open中会用类似如下的代码分配一块内存。
[cpp] view plain copy
1. file->private_data = kmalloc(sizeof(struct xxx), GFP_KERNEL);
然后在接下来的read/write/ioctl中，我们就可以通过file->private_data取到与此文件关联的数据。
最后，在xxx_release中，我们会释放file->private_data指向的内存。
如果只是上面这几种流程访问file->private_data所指向的数据，基本上不会出问题。
因为内核的文件系统框架已经做了很完善的处理。
对于迸发访问，我们自己也可以通过锁等机制来解决。
然而，我们通常还会在一些异步的流程中访问file->private_data所指向的数据，这些异步流程可能由定时器，中断，进程间通信等因素触发。
并且，这些流程访问数据时，没有经过内核的文件系统框架。
那么这就有可能导致出现问题了。
下面我们先来看看内核文件系统框架的部分实现代码，再来考虑如何规避可能出现的问题。我们的分析基于linux-3.10.102的内核源码。
首先，要得到一个fd，必须先有一次调用C库函数open的行为。而在C库函数open返回之前，其他线程得不到fd，当然也就不会对此fd进行操作。等拿到fd时，open操作都已经完成了。
实际上，更夸张的情况还是有可能存在的。例如，可能由于程序的错误甚至是程序员故意构造特殊代码，导致在open返回之前，其他线程就使用即将返回的fd进行文件操作了。这种情况，这里就不讨论了。有兴趣的朋友，可以自己钻研内核代码，看看会产生什么效果。
先看看文件打开操作的主要函数调用：
sys_open, do_sys_open, do_filp_open, fd_install, __fd_install。
安装fd的操作如下。可见这里是对文件表加了锁的，并且不是针对单个文件，是整体性的加锁。
[cpp] view plain copy
1. void __fd_install(struct files_struct *files, unsigned int fd,
2. struct file *file)
3. {
4. struct fdtable *fdt;
5. spin_lock(&files->file_lock);
6. fdt = files_fdtable(files);
7. BUG_ON(fdt->fd[fd] != NULL);
8. rcu_assign_pointer(fdt->fd[fd], file);
9. spin_unlock(&files->file_lock);
10. }
读写操作，代码结构非常相似。这里只看写操作吧。其实现如下：
[cpp] view plain copy
1. SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf,
2. size_t, count)
3. {
4. struct fd f = fdget(fd);
5. ssize_t ret = -EBADF;
6.
7. if (f.file) {
8. loff_t pos = file_pos_read(f.file);
9. ret = vfs_write(f.file, buf, count, &pos);
10. file_pos_write(f.file, pos);
11. fdput(f);
12. }
13.
14. return ret;
15. }
[cpp] view plain copy
1. ssize_t vfs_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
2. {
3. ssize_t ret;
4.
5. if (!(file->f_mode & FMODE_WRITE))
6. return -EBADF;
7. if (!file->f_op || (!file->f_op->write && !file->f_op->aio_write))
8. return -EINVAL;
9. if (unlikely(!access_ok(VERIFY_READ, buf, count)))
10. return -EFAULT;
11.
12. ret = rw_verify_area(WRITE, file, pos, count);
13. if (ret >= 0) {
14. count = ret;
15. file_start_write(file);
16. if (file->f_op->write)
17. ret = file->f_op->write(file, buf, count, pos);
18. else
19. ret = do_sync_write(file, buf, count, pos);
20. if (ret > 0) {
21. fsnotify_modify(file);
22. add_wchar(current, ret);
23. }
24. inc_syscw(current);
25. file_end_write(file);
26. }
27.
28. return ret;
29. }
[cpp] view plain copy
1. ssize_t do_sync_write(struct file *filp, const char __user *buf, size_t len, loff_t *ppos)
2. {
3. struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };
4. struct kiocb kiocb;
5. ssize_t ret;
6.
7. init_sync_kiocb(&kiocb, filp);
8. kiocb.ki_pos = *ppos;
9. kiocb.ki_left = len;
10. kiocb.ki_nbytes = len;
11.
12. ret = filp->f_op->aio_write(&kiocb, &iov, 1, kiocb.ki_pos);
13. if (-EIOCBQUEUED == ret)
14. ret = wait_on_sync_kiocb(&kiocb);
15. *ppos = kiocb.ki_pos;
16. return ret;
17. }
可以看出，读写操作是无锁的。也不好加锁，因为读写操作，还有ioctl，有可能阻塞。如果需要锁，用户自己可以使用文件锁，《UNIX环境高级编程》中有关于文件锁的描述。
不过fdget与fdput中包含了一些rcu方面的操作，那是为了能够与close fd的操作迸发进行。[!--empirenews.page--]
另外，可以看出，如果只实现一个f_op->aio_write，也是可以支持C库函数write的。
再来看看ioctl的实现。
[cpp] view plain copy
1. SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
2. {
3. int error;
4. struct fd f = fdget(fd);
5.
6. if (!f.file)
7. return -EBADF;
8. error = security_file_ioctl(f.file, cmd, arg);
9. if (!error)
10. error = do_vfs_ioctl(f.file, fd, cmd, arg);
11. fdput(f);
12. return error;
13. }
对于非常规文件，或者常规文件中文件系统特有的命令，最终都会走到
filp->f_op->unlocked_ioctl
另外，ioctl也是无锁的。同时，流程中包含了fdget与fdput，这一点与read/write一样。
再来看看关闭文件的操作。系统调用sys_close的实现如下(fs/open.c)
[cpp] view plain copy
1. SYSCALL_DEFINE1(close, unsigned int, fd)
2. {
3. int retval = __close_fd(current->files, fd);
4.
5. /* can‘t restart close syscall because file table entry was cleared */
6. if (unlikely(retval == -ERESTARTSYS ||
7. retval == -ERESTARTNOINTR ||
8. retval == -ERESTARTNOHAND ||
9. retval == -ERESTART_RESTARTBLOCK))
10. retval = -EINTR;
11.
12. return retval;
13. }
可见主要工作是__close_fd函数(fs/file.c)完成的，其代码如下。可见他是对进程的文件表加了锁的。因此，open、close操作是有互斥的，并且不是针对某一文件的互斥，而是整体的互斥。
对于close一个fd时，其他cpu上的线程若正要或正在读写此fd怎么办?可以看出，close操作并不会为此等待，而是直接继续操作。
其中的rcu_assign_pointer(fdt->fd[fd], NULL);清除了此fd与file结构的关联，因此在此之后通过此fd已经访问不到相应的file结构了。至于在此之前就发起了的且尚未结束的访问怎么处理，答案是在filp_close中处理。
[cpp] view plain copy
1. int __close_fd(struct files_struct *files, unsigned fd)
2. {
3. struct file *file;
4. struct fdtable *fdt;
5.
6. spin_lock(&files->file_lock);
7. fdt = files_fdtable(files);
8. if (fd >= fdt->max_fds)
9. goto out_unlock;
10. file = fdt->fd[fd];
11. if (!file)
12. goto out_unlock;
13. rcu_assign_pointer(fdt->fd[fd], NULL);
14. __clear_close_on_exec(fd, fdt);
15. __put_unused_fd(files, fd);
16. spin_unlock(&files->file_lock);
17. return filp_close(file, files);
18.
19. out_unlock:
20. spin_unlock(&files->file_lock);
21. return -EBADF;
22. }
filp_close又调用了fput, 后者的相关代码如下。可见当前任务若非内核线程，接下来就是走____fput，否则就是走delayed_fput。
但是最终都是走__fput，__fput中会调用file->f_op->release，即我们的xxx_release。
不过，从fput代码可以看出，____fput会由rcu相关的work触发。因此，可以预见当____fput被调用时，已经没有已经发生且尚未结束的针对此文件的访问流程了。
[cpp] view plain copy
1. static void ____fput(struct callback_head *work)
2. {
3. __fput(container_of(work, struct file, f_u.fu_rcuhead));
4. }
5.
6.
7. void flush_delayed_fput(void)
8. {
9. delayed_fput(NULL);
10. }
11.
12. static DECLARE_WORK(delayed_fput_work, delayed_fput);
13.
14. void fput(struct file *file)
15. {
16. if (atomic_long_dec_and_test(&file->f_count)) {
17. struct task_struct *task = current;
18.
19. if (likely(!in_interrupt() && !(task->flags & PF_KTHREAD))) {
20. init_task_work(&file->f_u.fu_rcuhead, ____fput);
21. if (!task_work_add(task, &file->f_u.fu_rcuhead, true))
22. return;
23. }
24.
25. if (llist_add(&file->f_u.fu_llist, &delayed_fput_list))
26. schedule_work(&delayed_fput_work);
27. }
28. }
现在再来想想，我们上面提到的那些访问file->private_data所指向的数据的异步流程，这些流程并没有走文件系统框架。
会不会出现这种情况，xxx_release已经执行过了，可是异步流程却还来访问file->private_data所指向的数据呢?
其实xxx_release不妨不要释放file->private_data指向的内存，而是标记一下他的状态为已关闭。然后异步流程再访问此数据时，先检查一下状态。
若为已关闭，则妥善处理并释放即可。
下载文档
