start_renaming(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… start_renaming β€” like, the actual manual page

okay so this is start_renaming(9) from the Kernel API Manual (yes, section 9, kernel-land, we're fancy) and bestie, let me tell you what it does ✨


🌸 NAME 🌸

start_renaming β€” it looks up and locks names for rename, and it does the permission checking too 🫢


✨ SYNOPSIS ✨

int start_renaming (struct renamedata *rd , int lookup_flags , struct
qstr *old_last , struct qstr *new_last );

πŸŽ€ ARGUMENTS πŸŽ€

  • rd β€” the rename data, and she's carrying everything: the parents, the flags, and she's also the one who receives the found dentries on the way out πŸ’–
  • lookup_flags β€” extra flags you wanna pass along to ->lookup, like LOOKUP_REVAL, LOOKUP_NO_SYMLINKS etc. whatever your heart desires ✨
  • old_last β€” the name of the object living in rd.old_parent
  • new_last β€” the name of the object living in rd.new_parent

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so picture this: you look up two names and then make sure the locks are actually in place for the rename. That's the whole vibe check πŸ”₯

On success, the dentries you found get stored in rd.old_dentry and rd.new_dentry. Also β€” important β€” the refcount on rd->old_parent gets increased. Those references and the lock get dropped by end_renaming, so don't you dare think you can just hang onto them, ngl.

The qstrs you pass in don't need to have the hash calculated β€” it's giving low-effort-on-your-end, we handle it. And basic eXecute permission checking gets performed against rd.mnt_idmap πŸ’…


⭐ RETURN ⭐

zero, or an error. That's it, that's the whole return section 😭 (zero means slay, anything else means go read errno)


πŸ‘‘ SEE ALSO πŸ‘‘

This is the part where the manpage goes absolutely feral with the cross-references, and honestly? Iconic. Main character energy is the whole Kernel file ./fs/namei.c:

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_dentry(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)

like, go read all of them, iykyk πŸ’€πŸ’œ


ngl the whole thing lives in ./fs β€” that's the source, and this gorgeous page is dated October 2026, version start_renaming(9). bye bestie, go rename something responsibly πŸ§šβ€β™€οΈπŸŒΈ
πŸ“¦ where this page comes from