Patch "file: Implement task_lookup_next_fd_rcu" has been added to the 5.10-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    file: Implement task_lookup_next_fd_rcu

to the 5.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     file-implement-task_lookup_next_fd_rcu.patch
and it can be found in the queue-5.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit ab786a84301ccd4708199bd45f66c5660301e09e
Author: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
Date:   Fri Nov 20 17:14:31 2020 -0600

    file: Implement task_lookup_next_fd_rcu
    
    [ Upstream commit e9a53aeb5e0a838f10fcea74235664e7ad5e6e1a ]
    
    As a companion to fget_task and task_lookup_fd_rcu implement
    task_lookup_next_fd_rcu that will return the struct file for the first
    file descriptor number that is equal or greater than the fd argument
    value, or NULL if there is no such struct file.
    
    This allows file descriptors of foreign processes to be iterated
    through safely, without needed to increment the count on files_struct.
    
    Some concern[1] has been expressed that this function takes the task_lock
    for each iteration and thus for each file descriptor.  This place
    where this function will be called in a commonly used code path is for
    listing /proc/<pid>/fd.  I did some small benchmarks and did not see
    any measurable performance differences.  For ordinary users ls is
    likely to stat each of the directory entries and tid_fd_mode called
    from tid_fd_revalidae has always taken the task lock for each file
    descriptor.  So this does not look like it will be a big change in
    practice.
    
    At some point is will probably be worth changing put_files_struct to
    free files_struct after an rcu grace period so that task_lock won't be
    needed at all.
    
    [1] https://lkml.kernel.org/r/20200817220425.9389-10-ebiederm@xxxxxxxxxxxx
    v1: https://lkml.kernel.org/r/20200817220425.9389-9-ebiederm@xxxxxxxxxxxx
    Link: https://lkml.kernel.org/r/20201120231441.29911-14-ebiederm@xxxxxxxxxxxx
    Signed-off-by: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
    Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/fs/file.c b/fs/file.c
index 60a3ccba728cd..9fa49e6298fba 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -926,6 +926,27 @@ struct file *task_lookup_fd_rcu(struct task_struct *task, unsigned int fd)
 	return file;
 }
 
+struct file *task_lookup_next_fd_rcu(struct task_struct *task, unsigned int *ret_fd)
+{
+	/* Must be called with rcu_read_lock held */
+	struct files_struct *files;
+	unsigned int fd = *ret_fd;
+	struct file *file = NULL;
+
+	task_lock(task);
+	files = task->files;
+	if (files) {
+		for (; fd < files_fdtable(files)->max_fds; fd++) {
+			file = files_lookup_fd_rcu(files, fd);
+			if (file)
+				break;
+		}
+	}
+	task_unlock(task);
+	*ret_fd = fd;
+	return file;
+}
+
 /*
  * Lightweight file lookup - no refcnt increment if fd table isn't shared.
  *
diff --git a/include/linux/fdtable.h b/include/linux/fdtable.h
index a88f68f740677..b0c6a959c6a00 100644
--- a/include/linux/fdtable.h
+++ b/include/linux/fdtable.h
@@ -111,6 +111,7 @@ static inline struct file *lookup_fd_rcu(unsigned int fd)
 }
 
 struct file *task_lookup_fd_rcu(struct task_struct *task, unsigned int fd);
+struct file *task_lookup_next_fd_rcu(struct task_struct *task, unsigned int *fd);
 
 struct task_struct;
 




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux