vfs_mkdir(9)

💖 vfs_mkdir — like, the kernel's "make a folder" moment (from the Kernel API Manual, bestie) 💖

okay so picture this: you wanna create a directory, but you also want the dentry situation handled correctly if the fs decides to be weird about it. that's literally this function. she does the most and we love her for it 🫶

---

✨ SYNOPSIS ✨

struct dentry * vfs_mkdir (struct mnt_idmap *idmap , struct inode *dir ,
struct dentry *dentry , umode_t mode , struct delegated_inode
*delegated_inode );

that's the whole signature, no cap. five args, one struct dentry * back. 💅

---

🌸 ARGUMENTS 🌸

• idmap — the idmap of the mount that the inode was found from. yes you need it, no you can't skip it (see the description below, ikyk).
• dir — the inode of the parent directory. the mother ship. the one who's getting a new child folder. 👑
• dentry — the dentry of the child directory. your new baby.
• mode — the mode of the child directory. permissions vibe check.
• delegated_inode — returns the parent inode, if the inode is delegated. conditional queen. 💀

---

🦋 DESCRIPTION 🦋

Create a directory. that's it. that's the tweet. ✨

but okay here's the lore. if the inode has been found through an idmapped mount, you must pass the idmap of the vfsmount through idmap. she'll then take care to map the inode according to idmap before checking permissions — so the permission check happens on the mapped version, not the raw one. we stan a careful icon.

lowkey important: on non-idmapped mounts, or if the permission checking is to be performed on the raw inode, just pass nop_mnt_idmap and move on. ngl that's the whole trick. 🎀

now for the dentry drama, because there is dentry drama:

• In the event that the filesystem does not use the *dentry but leaves it negative or unhashes it, and possibly splices a different one and returns that one — the original dentry gets dput'd and the alternate one is returned. so like, you might not get back the dentry you handed in. plot twist. 😭
• In case of an error, the dentry is dput'd and an ERR_PTR is returned. so check for errors, bestie, fr fr. don't just raw-dog the return value. 💀

---

🧚 SEE ALSO 🧚

all the siblings and cousins, in the order the kernel lists them (don't come for me, I kept every single one):

Kernel file ./fs/namei.c — and then: 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_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_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).

that's the whole extended fam right there. ate. 🔥

---

and that's the page, bestie!! 🎀💜 it lives under ./fs, dated October 2026, and it's giving main-character kernel documentation energy. go make some directories (correctly, with the right idmap, and please IS_ERR your return value 💅✨).