Linux中的fget_light有什么用？

Question

我正在研究Linux中的系统调用,我读了read()系统调用.

SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
{
    struct file *file;
    ssize_t ret = -EBADF;
    int fput_needed;

    file = fget_light(fd, &fput_needed);
    if (file) {
        loff_t pos = file_pos_read(file);
        ret = vfs_read(file, buf, count, &pos);
        file_pos_write(file, pos);
        fput_light(file, fput_needed);
    }

    return ret;
}

这是fget_light()的定义

struct file *fget_light(unsigned int fd, int *fput_needed)
 {
         struct file *file;
         struct files_struct *files = current->files;

         *fput_needed = 0;
         if (likely((atomic_read(&files->count) == 1))) {
                 file = fcheck_files(files, fd);
         } else {
                 rcu_read_lock();
                 file = fcheck_files(files, fd);
                 if (file) {
                         if (atomic_long_inc_not_zero(&file->f_count))
                                 *fput_needed = 1;
                         else
                                 /* Didn't get the reference, someone's freed */
                                 file = NULL;
                 }
                 rcu_read_unlock();
         }

         return file;
 }

你能解释一下,fget_light做什么？

Answer 1

每个任务都有一个文件描述符表.此文件描述符表由文件描述符编号索引,并包含有关每个打开文件的信息(文件描述).

与内核中的许多其他对象一样,文件描述也是引用计数的.这意味着当内核的某些部分想要访问文件描述时,它必须采用引用,做它需要做的任何事情,并释放引用.当引用计数降为零时,可以释放该对象.对于文件描述,open()增加引用计数并close()递减它,因此文件描述在打开和/或内核使用时无法释放(例如:想象一个线程在处理close()文件而另一个线程仍然read()在文件中:文件描述实际上不会被释放,直到读取fput()它的引用).

要从文件描述符获取对文件描述的引用,内核具有该函数fget(),并fput()释放该引用.由于多个线程可以同时在不同的CPU访问同一文件的描述,fget()并且fput()必须使用适当的锁定.在现代,他们使用RCU; 仅仅是文件描述符表的读者不会/几乎没有成本.

但是RCU还不够优化.考虑到拥有非多线程的进程是很常见的.在这种情况下,您不必担心访问相同文件描述的同一进程中的其他线程.访问我们的文件描述符表的唯一任务是我们.因此,作为优化,当当前文件描述符表仅用于单个任务时,fget_light()/ fput_light()不接触引用计数.

struct file *fget_light(unsigned int fd, int *fput_needed)
{
     struct file *file;
     /* The file descriptor table for our _current_ task */
     struct files_struct *files = current->files;

     /* Assume we won't need to touch the reference count, 
      *  since the count won't reach zero (we are not close(), 
      *  and hope we don't run concurrently to close()),
      *  fput_light() won't actually need to fput().
      */
     *fput_needed = 0;

     /* Check whether we are actually the only task with access to the fd table */
     if (likely((atomic_read(&files->count) == 1))) {
             /* Yep, get the reference to the file description */
             file = fcheck_files(files, fd);
     } else {
             /* Nope, we'll need some locking */
             rcu_read_lock();
             /* Get the reference to the file description */
             file = fcheck_files(files, fd);
             if (file) {
                     /* Increment the reference count */
                     if (atomic_long_inc_not_zero(&file->f_count))
                             /* fput_light() will actually need to fput() */
                             *fput_needed = 1;
                     else
                             /* Didn't get the reference, someone's freed */
                             /* Happens if the file was close()d and all the 
                              *  other accessors ended its work and fput().
                              */
                             file = NULL;
             }
             rcu_read_unlock();
     }

     return file;
}