lookup_one_p...ive_killable(9)

💅 lookup_one_positive_killable — Kernel API Manual ✨

okay so bestie, buckle up, because we're looking at lookup_one_positive_killable(9) from the Kernel API Manual. yes the title is a whole mouthful, i know, but it's iconic and we're gonna get through it together 🫶

---

🌸 NAME 🌸

lookup_one_positive_killable — lookup single pathname component. that's it. that's the whole vibe. one component, no cap 💅

---

🎀 SYNOPSIS 🎀

struct dentry * lookup_one_positive_killable (struct mnt_idmap *idmap ,
struct qstr *name , struct dentry *base );

look at her go. three args, one struct dentry * return, main character energy fr fr 👑

---

🦋 ARGUMENTS 🦋

• idmap — the idmap of the mount that the lookup is being performed from. like, which mount are we even doing this from, bestie? this tells you 🌈
• name — the qstr olding pathname component to lookup. literally just the one component, not the whole path, we're being specific here 💖
• base — the base directory to lookup from. your starting point, your home base, your safe space 🏠

---

⭐ DESCRIPTION ⭐

so here's the tea 🍵: this helper will yield ERR_PTR(-ENOENT) on negatives. yep. it returns known positive or ERR_PTR. and honestly? that's what most of the users want. it's giving "no surprises" and we love that for us ✨

⚠️ okay important one: a pinned negative with an unlocked parent _can_ become positive at any time 😭 so callers of lookup_one_unlocked need to be very careful. meanwhile pinned positives have >d_inode stable, so this one avoids such problems. she said "not me having that bug" and honestly? slay 🙈

this can be used for in-kernel filesystem clients such as file servers. very much "in the kernel, doing kernel things" energy 🧚

it should be called without the parent i_rwsem held, and it will take the i_rwsem itself if necessary — she's independent like that 💅 and if a fatal signal is pending or delivered, it will return -EINTR if the lock is needed. periodt.

---

🔥 RETURN 🔥

a dentry, possibly negative, OR:

• same errors as lookup_one_unlocked, or
• ERR_PTR(-EINTR) if a fatal signal is pending.

so yeah, you get a dentry or you get an error pointer. no in-between, no crumbs 💀

---

👑 SEE ALSO 👑

Kernel file ./fs/namei.c — and the whole entire friend group, because this function knows literally everyone:

• 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_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_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 i said. the whole group chat 🫶💜

---

and that's the page!! sign-off time: this came from ./fs, dated October 2026, and it's lookup_one_p...ive_killable(9) in case you need to find her again. bye bestie, go look up exactly one pathname component 💖🎀🦋