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.
