(lookup 2) vfs: add the infrastructure for lockless lookup

[mjg]

Summary

Assorted changes split out from the complete diff. Some have value on their own, but for the most part are only there for the new lookup.

[mjg]

• missing break

[kib]

sys/kern/kern_descrip.c

3354 ↗

(On Diff #74149)

I am still surprised with such loops. Don't you need yield sometimes ?

sys/kern/vfs_subr.c

3083 ↗

(On Diff #74149)

Why not extract this block from there and vget_finish() into a common function ?

[mjg]

sys/kern/kern_descrip.c

3354 ↗

(On Diff #74149)

If worrying about excessive looping, I think the right solution is to do the above once and in case of failure take the lock.

sys/kern/vfs_subr.c

3083 ↗

(On Diff #74149)

ok, will update later

[kib]

sys/kern/kern_descrip.c

3354 ↗

(On Diff #74149)

My concern that if we are on UP and mutator is preempted by this loop at the unlucky moment, system can be livelocked.

[mjg]

• rebase

does not address vref_smr yet

[mjg]

sys/kern/vfs_subr.c

3083 ↗

(On Diff #74149)

So I don't know how to name this. In the patchset I introduce vget_finish_ref later to facilitate WANTPARENT/!LOCKLEAF lookups, but I'm not going to call something like that from vref.

[kib]

sys/kern/vfs_subr.c

3083 ↗

(On Diff #74149)

I would call it vref_hold() or vget_ref_hold(). This name describes the action of the code.

[mjg]

• add vfs_smr_entered_load
• vget_finish_ref

sys/kern/vfs_subr.c

3083 ↗

(On Diff #74149)

I reworked the only consumer of vref_smr to use vget direclty instead, thus getting rid of the problem for the time being.

[mjg]

• add vn_load_data_smr