Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

vfs: fix description comment of vfs_lookup() #737

Closed
wants to merge 2 commits into from
Closed

vfs: fix description comment of vfs_lookup() #737

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d541fce
vfs: fix description comment of vfs_lookup()
ihoro May 8, 2023
f10cecf
vfs: bring vfs_lookup() description comment up to date
ihoro Jun 20, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
23 changes: 12 additions & 11 deletions sys/kern/vfs_lookup.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -840,36 +840,37 @@ vfs_lookup_failifexists(struct nameidata *ndp)
* Search a pathname.
* This is a very central and rather complicated routine.
*
* The pathname is pointed to by ni_ptr and is of length ni_pathlen.
* The pathname is pointed to by cn_nameptr and is of length ni_pathlen.
* The starting directory is taken from ni_startdir. The pathname is
* descended until done, or a symbolic link is encountered. The variable
* ni_more is clear if the path is completed; it is set to one if a
* descended until done, or a symbolic link is encountered. The cn_flags
* has ISLASTCN or'ed if the path is completed or ISSYMLINK or'ed if a
* symbolic link needing interpretation is encountered.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks that some time ago it was passed as ni_more variable as a flag, today it works with cn_flags bits instead.

*
* The flag argument is LOOKUP, CREATE, RENAME, or DELETE depending on
* The cn_nameiop is LOOKUP, CREATE, RENAME, or DELETE depending on
* whether the name is to be looked up, created, renamed, or deleted.
* When CREATE, RENAME, or DELETE is specified, information usable in
* creating, renaming, or deleting a directory entry may be calculated.
* If flag has LOCKPARENT or'ed into it, the parent directory is returned
* locked. If flag has WANTPARENT or'ed into it, the parent directory is
* If cn_flags has LOCKPARENT or'ed into it, the parent directory is returned
* locked. If it has WANTPARENT or'ed into it, the parent directory is
* returned unlocked. Otherwise the parent directory is not returned. If
* the target of the pathname exists and LOCKLEAF is or'ed into the flag
* the target of the pathname exists and LOCKLEAF is or'ed into the cn_flags
* the target is returned locked, otherwise it is returned unlocked.
* When creating or renaming and LOCKPARENT is specified, the target may not
* be ".". When deleting and LOCKPARENT is specified, the target may be ".".
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both statements seem to be outdated, probably it makes sense to simply remove them. As I see, at least two cases (RENAME+dot and DELETE+dot) work another way today - it simply returns with EINVAL regardless locking option.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's keep this as a followup... I'm going to merge this, but feel free to followup on this detail

*
* Overall outline of lookup:
*
* dirloop:
* identify next component of name at ndp->ni_ptr
* handle degenerate case where name is null string
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously it was mentioned to be done upon each dirloop iteration, but today it's done once before the loop.

*
* dirloop:
* identify next component of name at ndp->ni_cnd.cn_nameptr
* handle .. special cases related to capabilities, chroot, jail
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to mention a bit more cases related to the well-known subsystems.

* if .. and crossing mount points and on mounted filesys, find parent
* call VOP_LOOKUP routine for next component name
* directory vnode returned in ni_dvp, unlocked unless LOCKPARENT set
* component vnode returned in ni_vp (if it exists), locked.
* if result vnode is mounted on and crossing mount points,
* find mounted on vnode
* if more components of name, do next level at dirloop
* if VOP_LOOKUP returns ERELOOKUP, repeat the same level at dirloop
* return the answer in ni_vp, locked if LOCKLEAF set
* if LOCKPARENT set, return locked parent in ni_dvp
* if WANTPARENT set, return unlocked parent in ni_dvp
Expand Down