1

我正在研究 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 是做什么的？

4

2 回答 2

9

每个任务都有一个文件描述符表。该文件描述符表由文件描述符编号索引，并包含有关每个打开文件的信息（文件描述）。

与内核中的许多其他对象一样，文件描述是引用计数的。这意味着当内核的某些部分想要访问文件描述时，它必须获取一个引用，做它需要做的任何事情，然后释放这个引用。当引用计数降为零时，可以释放对象。对于文件描述，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;
}
于 2012-10-05T23:23:40.130 回答
1

基本上，该函数通过调用查看进程文件表的函数（这将是它的参数） ，将fd用户传递的系统调用转换为内核内部file结构指针的系统调用。有关更多信息，请阅读此。fcheck_filesfiles

于 2012-10-05T17:48:17.810 回答