start_creating_killable(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… start_creating_killable(9) β€” a Kernel API Manual moment ✨

ok so bestie, welcome to the Kernel API Manual, entry start_creating_killable(9). this one's about getting permission before you go making a name exist in a directory, and ngl it is highkey iconic πŸŽ€

🌸 NAME 🌸

start_creating_killable β€” get ready to create a given name, with permission checking and everything 🫢

✨ SYNOPSIS ✨

struct dentry * start_creating_killable (struct mnt_idmap *idmap ,
struct dentry *parent , struct qstr *name );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • idmap β€” the idmap of the mount, like its whole identity vibe πŸ’«
  • parent β€” the directory where you're preparing to create the name (the main character directory, fr)
  • name β€” the name that's gonna be created ✨

πŸ‘‘ DESCRIPTION πŸ‘‘

ok so here's the tea: locks get taken, and a lookup happens before you create an object in a directory. and permission checking (MAY_EXEC) is performed against idmap. no cap, that's the whole ritual πŸ•―οΈ

if the name already exists? you get a positive dentry back. slay, it's already there πŸ’…

if a signal is received, or was already pending β€” the function aborts with -EINTR. like it literally says "not me today" and bails 😭

πŸ”₯ RETURN πŸ”₯

a negative or positive dentry, or an error. that's it, that's the vibe check πŸ’€

🌈 SEE ALSO 🌈

literally the whole friend group, all from the 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_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_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)


🫢 and that's the page!! brought to you by the source ./fs, dated October 2026, in the Kernel API Manual β€” catch you on the next lookup, bestie πŸ’–πŸ§šβ€β™€οΈβ­

πŸ“¦ where this page comes from