try_lookup_noperm(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… try_lookup_noperm(9) πŸ’…

okay bestie, this one is straight out of the Kernel API Manual and it's serving β€œlook up one pathname component, no permission checking, no drama.” ✨


✨ NAME ✨

try_lookup_noperm β€” a filesystem helper that looks up a single pathname component. That's the whole job, and it ate. πŸŽ€

🌸 SYNOPSIS 🌸

struct dentry * try_lookup_noperm (struct qstr *name , struct dentry *base );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • name β€” a qstr storing the pathname component to lookup. It's giving β€œthe name tag at the door” energy 🏷️
  • base β€” the base directory to lookup from. This is the spot you're searching under, bestie πŸ“‚

πŸ’œ DESCRIPTION πŸ’œ

So what's the tea? It looks up a dentry by name in the dcache, returning NULL if it does not currently exist, or an error if there is a problem with the name. Simple, iconic, done.

The function does not try to create a dentry, and if one is found it doesn't try to revalidate it. No extra credit, no side quest πŸ’…

note note note: this routine is purely a helper for filesystem usage and should not be called by generic code. It does no permission checking. If you're generic code, this is not your main character moment πŸ™ˆ

No locks need be held β€” only a counted reference to base is needed. That's the vibe check: counted reference to base, no lock drama πŸ”₯

⭐ RETURN ⭐

Here's the return-value tea β˜•:

  • ref-counted dentry on success, or
  • NULL if name could not be found, or
  • ERR_PTR(-EACCES) if name is dot or dotdot or contains a slash or nul, or
  • ERR_PTR if fs provide ->d_hash, and this returned an error.

🌈 SEE ALSO 🌈

Kernel file ./fs/namei.c β€” and then the whole squad: 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), 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_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, bestie 🫢 source/version is ./fs, dated October 2026, and it's still try_lookup_noperm(9) β€” catch you in the next lookup πŸ’–

πŸ“¦ where this page comes from