[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 2 Feb 2022 10:17:34 -0500
From: Jason Andryuk <jandryuk@...il.com>
To: linux-kernel@...r.kernel.org
Cc: "Eric W . Biederman" <ebiederm@...ssion.com>,
Cyrill Gorcunov <gorcunov@...il.com>,
Jason Andryuk <jandryuk@...il.com>
Subject: [PATCH] kcmp: Comment get_file_raw_ptr() RCU usage
This usage of RCU appears wrong since the pointer is passed outside the
RCU region. However, it is not dereferenced, so it is "okay". Leave a
comment for the next reader.
Without a reference, these comparisons are racy, but even with their use
inside an RCU region, the result could go stale.
Signed-off-by: Jason Andryuk <jandryuk@...il.com>
---
I was looking for examples of task_lookup_fd_rcu()/files_lookup_fd_rcu()
and found this. It differed from the example given in
Documentation/filesystems/files.rst, so I was initially confused. A
comment seemed appropriate to avoid confusion.
kernel/kcmp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/kcmp.c b/kernel/kcmp.c
index 5353edfad8e1..4fb23f242e0f 100644
--- a/kernel/kcmp.c
+++ b/kernel/kcmp.c
@@ -63,6 +63,9 @@ get_file_raw_ptr(struct task_struct *task, unsigned int idx)
{
struct file *file;
+ /* This RCU locking is only present to silence warnings. The pointer
+ * value is only used for comparison and not dereferenced, so it is
+ * acceptable. */
rcu_read_lock();
file = task_lookup_fd_rcu(task, idx);
rcu_read_unlock();
--
2.34.1
Powered by blists - more mailing lists