VOP_LOOKUP(9)

✨ NAME ✨

VOP_LOOKUP — lookup a component of a pathname. okay bestie, this is the VOP_LOOKUP(9) page from the Kernel Developer's Manual — we're in kernel-dev land, and this routine is doing one tiny pathname component at a time. 💅

---

🌸 SYNOPSIS 🌸

#include <sys/param.h>
#include <sys/vnode.h>
#include <sys/namei.h>

int
VOP_LOOKUP(struct vnode *dvp, struct vnode **vpp,
    struct componentname *cnp);

🎀 DESCRIPTION 🎀

This entry point looks up a single pathname component in a given directory. Very “one name, one lookup” energy.

Its arguments are:

• dvp — the locked vnode of the directory to search.
• vpp — the address of a variable where the resulting locked vnode should be stored.
• cnp — the pathname component to be searched for. It is a pointer to a componentname structure defined as follows:

struct componentname {
        /*
         * Arguments to lookup.
         */
        u_long  cn_nameiop;     /* namei operation */
        u_long  cn_flags;       /* flags to namei */
        struct  thread *cn_thread;      /* thread requesting lookup */
        struct  ucred *cn_cred; /* credentials */
        int     cn_lkflags;     /* Lock flags LK_EXCLUSIVE or LK_SHARED */
        /*
         * Shared between lookup and commit routines.
         */
        char    *cn_pnbuf;      /* pathname buffer */
        char    *cn_nameptr;    /* pointer to looked up name */
        long    cn_namelen;     /* length of looked up component */
};

Okay so what’s the actual job? Convert a component of a pathname into a pointer to a locked vnode. This is a very central and rather complicated routine — highkey iconic, lowkey scary. If the file system is not maintained in a strict tree hierarchy, this can result in a deadlock situation. 😭 Not the vibe.

The cnp->cn_nameiop argument is LOOKUP, CREATE, RENAME, or DELETE, depending on the intended use of the object. When CREATE, RENAME, or DELETE is specified, information usable in creating, renaming, or deleting a directory entry may be calculated. 🫶

Overall outline of VOP_LOOKUP:

Check accessibility of directory.  Look for name in cache, if
found, then return name.  Search for name in directory, goto to
found or notfound as appropriate.

notfound:

      If creating or renaming and at end of pathname, return
      EJUSTRETURN, leaving info on available slots else return ENOENT.

found:

      If at end of path and deleting, return information to allow
      delete.  If at end of path and renaming, lock target inode and
      return info to allow rename.  If not at end, add name to cache; if
      at end and neither creating nor deleting, add name to cache.

🔒 LOCKS 🔒

The directory dvp should be locked on entry and exit, regardless of error condition. If an entry is found in the directory, it will be returned locked. Lock discipline is the moment, bestie. 💅

🫶 RETURN VALUES 🫶

Zero is returned with *vpp set to the locked vnode of the file if the component is found. If the component being searched for is ".", then the vnode just has an extra reference added to it with vref(9). The caller must take care to release the locks appropriately in this case.

If the component is not found and the operation is CREATE or RENAME, the flag ISLASTCN is specified and the operation would succeed, the special return value EJUSTRETURN is returned. Otherwise, an appropriate error code is returned.

💀 ERRORS 💀

• [ENOTDIR] — The vnode dvp does not represent a directory.
• [ENOENT] — The component dvp was not found in this directory.
• [EACCES] — Access for the specified operation is denied.
• [EJUSTRETURN] — A CREATE or RENAME operation would be successful.

🌈 SEE ALSO 🌈

vnode(9), VOP_ACCESS(9), VOP_CREATE(9), VOP_MKDIR(9), VOP_MKNOD(9), VOP_RENAME(9), VOP_SYMLINK(9) — go read those too, bestie. 📚

🦋 HISTORY 🦋

The function VOP_LOOKUP appeared in 4.3BSD. Old-school but still slaying. ✨

👑 AUTHORS 👑

This manual page was written by Doug Rabson, with some text from comments in ufs_lookup.c. 🫶

---

Debian • August 8, 2018 • VOP_LOOKUP(9) — mwah 💖