vfs_prepare_mode(9)

💅 vfs_prepare_mode(9) 💅

Okay so this is a page straight out of the Kernel API Manual, and honestly? It's a little baddie of a helper that deserves way more hype than it gets. Bestie, let's get into it — vfs_prepare_mode is literally out here doing the vibe check on file modes before anything gets created. Iconic behaviour, no cap. 🎀

---

✨ NAME ✨

vfs_prepare_mode — prepare the mode to be used for a new inode 🦋

Like, get the mode ready. That's the whole job. She's a preparer, a little pre-game ritual for inodes. 🌸

---

🌈 SYNOPSIS 🌈

umode_t vfs_prepare_mode (struct mnt_idmap *idmap , const struct inode
*dir , umode_t mode , umode_t mask_perms , umode_t type );

Yes she takes five arguments, yes she's high maintenance, and yes she's worth it. Read the next section before you @ me. 💅

---

🔥 ARGUMENTS 🔥

• idmap — the idmap of the mount that the inode was found from. iykyk, it's the id mapping situation for wherever this inode lives. 🗺️
• dir — the parent directory of the new inode. Your new file's mom, basically. 🫶
• mode — the mode of the new inode. The permissions aesthetic she's serving. ✨
• mask_perms — the allowed permission by the vfs. The vfs sets the boundaries, she respects them. 🚧
• type — the type of file to be created. Regular? Directory? Something spicier? You tell her. 🍓

---

💖 DESCRIPTION 💖

Okay so picture this: this helper ⭐ consolidates ⭐ and ⭐ enforces ⭐ the vfs restrictions on the mode of a brand-new object that's about to be created. She's the one making sure the rules are followed before anything gets to exist. Main character energy, fr fr.

Now the interesting part 💀 — umask stripping depends on whether the filesystem supports POSIX ACLs. (See the kernel documentation for mode_strip_umask, bestie, it's literally right there and it explains the whole thing.) 👑

Moving umask stripping after setgid stripping is what allows the same ordering for both non-POSIX ACL filesystems and POSIX ACL supporting filesystems. So like, one consistent order for everybody. Slay. Ordering matters and she's not about to let it get messy. 🎀

---

👑 RETURN 👑

The mode to be passed to the filesystem. That's it, that's the tea. She hands you back the prepared mode and you go live your life. 🦋

---

🫶 SEE ALSO 🫶

Honestly this list is giving deep lore, and there's a Kernel file involved — ./fs/namei.c — so buckle up, bestie. Every single one of these is part of the saga:

• 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_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)

---

💀 Friendly reminder that this page lives under ./fs and is dated October 2026 — so if you're reading this from the future, hiiii, hope the kernel's still slaying.

Okay that's the whole page, bestie! Go forth and prepare those modes. Periodt. 🌈💅✨