kernfs: take kernfs_rename_lock for same-parent renames too

kernfs_rename_ns() takes kernfs_rename_lock only when the rename moves
the node to a new parent.  A rename that keeps the parent, like renaming
a network interface, changes kernfs_node::name under kernfs_rwsem alone.
So the lock covers ->__parent but not ->name, and a reader that wants a
stable name has to take kernfs_rwsem, the lock every lookup needs.

It is also a real bug.  kernfs_path_from_node() holds the lock for
reading and reads each ancestor's name once.  One rename only moves the
answer from the old path to the new one, but two renames inside one walk
build a path that never existed:

  CPU0                                   CPU1
  kernfs_path_from_node() on /a/b/c
    reads the name of a, gets "a"
                                         renames a to a2
                                         renames b to b2
    reads the name of b, gets "b2"
    returns "/a/b2/c"

Only sysfs can hit this: sysfs_warn_dup() is the one caller on a root
without KERNFS_ROOT_INVARIANT_PARENT.  The rest are cgroup, which sets
the flag, so it skips the lock and reads names under RCU alone.  That
case needs something else and is left alone here.

So take the lock for both kinds of rename, and let kernfs_rcu_name()
accept it, like kernfs_parent() already does for ->__parent.  Renames
are rare, the lock is per filesystem, and the locked section is at most
three stores.  It also gives a future rename counter one place to sit.

Fixes: 741c10b096bc ("kernfs: Use RCU to access kernfs_node::name.")
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
Link: https://patch.msgid.link/20260905191613.3143937-3-shakeel.butt@linux.dev
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

0 files changed, 0 insertions, 0 deletions