linux - 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;
}