Re: [PATCH 2/2] fs/proc: take rcu_read_lock() in proc_sys_compare()

[Al Viro]

On Thu, Jun 12, 2025 at 08:57:03AM +1000, NeilBrown wrote:

> However there is no guarantee that this lock is held by d_same_name()
> (the caller of ->d_compare).  In particularly d_alloc_parallel() calls
> d_same_name() after rcu_read_unlock().

d_alloc_parallel() calls d_same_name() with dentry being pinned;
if it's positive, nothing's going to happen to its inode,
rcu_read_lock() or not.  It can go from negative to positive,
but that's it.

Why is it needed?  We do care about possibly NULL inode (basically,
when RCU dcache lookup runs into a dentry getting evicted right
under it), but that's not relevant here.