start_renaming_dentry(9)

💅 start_renaming_dentry — kernel API manual, bestie edition ✨

okay so this is a page from the Kernel API Manual, and honestly? it's a whole vibe. it's about getting a name looked up and locked down so a rename can happen. let's go 🦋

---

✨ NAME ✨

start_renaming_dentry — lookup and lock name for rename with permission checking

like, you want to rename a thing? this is the function that goes "okay hold on, let me find that name and lock it first, and also check you're actually allowed to do this." main character energy fr 👑

---

🌸 SYNOPSIS 🌸

int start_renaming_dentry (struct renamedata *rd , int lookup_flags ,
       struct dentry *old_dentry , struct qstr *new_last );

that's the whole signature, keep it exactly like that, no cap 💖

---

🎀 ARGUMENTS 🎀

• rd — the rename data. it's carrying the parents and the flags, and it's also there to receive the dentries we find. so it's giving both directions, iconic 🫶
• lookup_flags — extra flags you pass straight through to ->lookup (stuff like LOOKUP_REVAL, LOOKUP_NO_SYMLINKS etc). yes, "etc" is doing a lot of work there, but that's what the original says 🙈
• old_dentry — the dentry of the name you want to move
• new_last — the name of the target, inside rd.new_parent

---

💜 DESCRIPTION 💜

So the whole point: look up the target name and make sure the locks are in place for the rename. that's it, that's the job ✨

On success, the found dentry gets stored in rd.new_dentry, and rd.old_parent is confirmed to be the parent of old_dentry. if rd.old_parent was originally NULL, it gets set. either way, a reference is taken — that's so end_renaming has a stable reference it can use to unlock. no dangling, no drama 💅

You can drop the references and the lock later with end_renaming. clean exit, we love to see it.

Also, the qstr you pass in doesn't need to have its hash calculated — lowkey convenient. And basic eXecute permission checking gets performed against rd.mnt_idmap. so it's not just vibes, it's actual permission checking 🔥

---

⭐ RETURN ⭐

zero or an error. that's the whole return section, she's short and to the point 😭

if it's not zero, bestie, something went wrong — handle it.

---

🌈 SEE ALSO 🌈

okay this list is LONG, like a group chat that never stops typing, but every single one of these is a real page in the kernel source at ./fs/namei.c and i'm not skipping a single one:

check_acl(9), acl_permission_check(9), generic_permission(9), do_inode_permission(9), sb_permission(9), inode_permission(9), path_get(9), path_put(9), path_connected(9), try_to_unlazy(9), try_to_unlazy_next(9), complete_walk(9), may_follow_link(9), safe_hardlink_source(9), may_linkat(9), may_create_in_sticky(9), lookup_fast(9), start_dirop(9), end_dirop(9), kern_path_parent(9), vfs_path_parent_lookup(9), vfs_path_lookup(9), try_lookup_noperm(9), lookup_noperm(9), lookup_one(9), lookup_one_unlocked(9), lookup_one_positive_killable(9), lookup_one_positive_unlocked(9), lookup_noperm_unlocked(9), start_creating(9), start_removing(9), start_creating_killable(9), start_removing_killable(9), start_creating_noperm(9), start_removing_noperm(9), start_creating_dentry(9), start_removing_dentry(9), __start_renaming(9), start_renaming(9), start_renaming_two_dentries(9), vfs_prepare_mode(9), vfs_create(9), atomic_open(9), vfs_lookup_open(9), vfs_tmpfile(9), kernel_tmpfile_open(9), end_creating_path(9), dentry_create(9), vfs_mknod(9), vfs_mkdir(9), vfs_rmdir(9), vfs_unlink(9), vfs_symlink(9), vfs_link(9), vfs_rename(9), vfs_readlink(9), vfs_get_link(9), page_get_link(9), page_put_link(9)

---

and that's the page!! 🎀 she lives at ./fs, this edition is from October 2026, and she's page start_renaming_dentry(9) of the Kernel API Manual — go forth and rename responsibly bestie, ily 💖✨