Add vrefl(), a locked variant of vref()

[markj]

Summary

A variation of this change is used in Isilon's filesystem.

[kib]

I do not object against vrefl(), but I am curious where do you want to use this ?

Also, please consider using D4953.

[mjg]

if this change was to go in, I would suggest folding v_incr_usecount into vref (which maybe should happen anyway) and for consitency dealing with it like with vhold, where both vhold and vholdl are macros which expand to a _vhold call.

Do you have a particular use for vrefl?

[markj]

I don't have a specific in-tree use at the moment - I'm working on some integration problems between Isilon's FS and recent revisions of FreeBSD. Isilon currently makes v_incr_usecount() externally visible to use as a locked vref(), but this broke with r285632. I just want to fix this in a clean way.

I realize that adding a new API without consumers is questionable at best. In this case I believe it's reasonable since:

• the change is small, and
• it naturally complements the existing vnode refcount manipulation API.

Does that seem like a valid justification here? In general I avoid using internal Isilon code to justify changes to FreeBSD. I'm happy to test and commit the alternative implementation.

[kib]

In D4947#105079, @markj wrote:

Does that seem like a valid justification here? In general I avoid using internal Isilon code to justify changes to FreeBSD. I'm happy to test and commit the alternative implementation.

As I said, I do not object against vrefl().

[markj]

Superseded by D4953.