The ->sysctl field of a procfs inode is only set when the inode is
created, and when it is being evicted.  In both these cases there cannot
be concurrent accesses and so using RCU_INIT_POINTER() and
rcu_dereference() is misleading.

I discovered this with some devel code which called d_same_name()
without holding the rcu_read_lock() - rcu_dereference() triggered a
warning.  In mainline ->d_compare is called from d_alloc_parallel()
without rcu_read_lock() after taking ->d_lock.  It is conceivable that
the d_inode will have been set while waiting for that lock so mainline
could trigger the same warning.

This patch removes those accessor call.  Note that the sysctl field is
not marked __rcu so sparse complains too.

Signed-off-by: NeilBrown <neil@brown.name>
---
 fs/proc/inode.c       | 2 +-
 fs/proc/proc_sysctl.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index a3eb3b740f76..c3991dd314d9 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -42,7 +42,7 @@ static void proc_evict_inode(struct inode *inode)
 
 	head = ei->sysctl;
 	if (head) {
-		RCU_INIT_POINTER(ei->sysctl, NULL);
+		ei->sysctl = NULL;
 		proc_sys_evict_inode(inode, head);
 	}
 }
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index cc9d74a06ff0..976d7605560f 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -928,7 +928,7 @@ static int proc_sys_compare(const struct dentry *dentry,
 		return 1;
 	if (memcmp(name->name, str, len))
 		return 1;
-	head = rcu_dereference(PROC_I(inode)->sysctl);
+	head = PROC_I(inode)->sysctl;
 	return !head || !sysctl_is_seen(head);
 }
 
-- 
2.49.0

On Fri, Jun 13, 2025 at 12:52:32PM +1000, NeilBrown wrote:
> 
> The ->sysctl field of a procfs inode is only set when the inode is
> created, and when it is being evicted.  In both these cases there cannot
> be concurrent accesses and so using RCU_INIT_POINTER() and
> rcu_dereference() is misleading.

Wait a minute.  Why can't there be concurrent accesses?  ->evict_inode()
is *before* RCU delay, not after it.

Sure, you can't hit it from d_alloc_parallel(), but you very much can
in normal dcache lookup...