atomic_open(9)

💅 atomic_open(9)

okay so bestie, welcome to atomic_open from the Kernel API Manual — this is the one that does the look-up + create + open all in one go, no cap ✨

---

🌸 NAME 🌸

atomic_open — atomically look up, create and open a file. one shot, one kill, the whole trilogy in a single syscall-adjacent moment 👑

---

🦋 SYNOPSIS 🦋

struct dentry * atomic_open (const struct path *path , struct dentry
*dentry , struct file *file , int open_flag , umode_t mode , int
create_error );

---

🎀 ARGUMENTS 🎀

• path — the parent directory path, i.e. where we're hanging out 🏠
• dentry — the child that gets passed to ->atomic_open
• file — the file we're attaching said child to
• open_flag — the open flags, the little settings gremlins
• mode — the create mode
• create_error — the return value from may_o_create, so like, the vibe report on whether we're allowed to create 🫶

---

✨ DESCRIPTION ✨

So the whole point: it attempts to look up, create and open dentry — which must be negative — in a single call into the filesystem. one trip, no backtracking, we love efficiency 💅

If a non-error dentry comes back, here's the tea 🍓:

• when FMODE_OPENED is set, the file will have been attached to file by the filesystem calling finish_open
• if FMODE_OPENED isn't set, the filesystem instead called finish_no_open, and the caller will need to perform the open themselves — yes, you, you're doing it, good luck bestie 😭

FMODE_CREATED is set when the call to ->atomic_open actually created the file. slay, it's new ✨

---

🔥 RETURN 🔥

the opened or looked-up dentry, or ERR_PTR on failure. and listen — the reference to dentry is consumed in either case, so don't come for it later, it's gone, periodt 💀

ngl this one's important: success or failure, the dentry reference is consumed. no double-dipping, no take-backs 🚫

---

🌈 SEE ALSO 🌈

Kernel file ./fs/namei.c — and the whole friend group:

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

---

okay that's the whole page, you ate that 🫶 this one lives in ./fs and it's dated October 2026 in the Kernel API Manual — mwah, go read namei.c, ily, bye 💖🧚‍♀️