I've brought this up before, but I do maintain an out-of-tree sound driver (multimedia/cx88) that happens to use these version constants; for all I know I may be the only person who still uses it at this point, but I'm the maintainer so that's what matters.
I also don't think it's safe to assume there aren't other such drivers (ISTR there was at least one other one that was related to some graphics kmod).

Is there some situation in which we expect dvp and vp to be the same, without the caller taking steps to avoid using VOP_VPUT_PAIR() in the first place?

In D53988#1237668, @olce wrote:

In D53988#1237096, @jah wrote:

I made exactly this change in my original heavyweight attempt at unionfs_getlowvnode (which did do the copy-up and thus required the vnode lock). But as a practical concern, I think the nullfs issue you mentioned above could be just as easily dealt with by changing null_getlowvnode() to take the interlock instead of the full vnode lock. We might still want to change this contract anyway, but I think that should be done as a separate change, no?

You're right, doing it separately doesn't hurt, as VOP_GETLOWVNODE() is currently never called with a lock.

This is what I did in the initial posted version of this change; you can still see that version in the diff history here, along with the conversation with kib@ that resulted in the change to return EACCES instead.

Oh sorry, I read it, but apparently too quickly. I missed that the top-level VOP_GETLOWVNODE() calls are all triggered through the copy_file_range() system calls, for which users must have opened the file, leading to VOP_OPEN() being called first (if we except the NFS case).

All in all, this is an improvement with no drawbacks, it should go, sorry for the delay.

In D53988#1236975, @olce wrote:

I don't think just having unionfs_getlowvnode() return EACCESS alone is enough, it has problems, see inline comment.

I'm not sure we should expect unionfs_getlowvnode() to copy up the file. This indeed complicates code for an accessor, and perhaps more importantly brings the question of the semantics of VOP_GETLOWVNODE(), especially when called with F_WRITE.

There are currently only two callers of VOP_GETLOWVNODE(), one is null_getlowvnode(), the other vn_copy_file_range(), and only the latter uses F_WRITE. nullfs' implementation will not work if the vnode is locked on entry. Also, it does not guarantee the same locking for the output vnode at all (and I don't think it should).

Given all this, here's what I propose:

1. Change part of the contract of VOP_GETLOWVNODE() with respect to locking and error: Use U U - (input vnode is unlocked, output is unlocked, and no vnode returned on error).

Return error if no upper vnode present

Do we have automated tests for rm(1) somewhere that I'll need to change?

There are probably a lot of different ways to do this. Initially I just did the obvious thing and made iommu_bus_dma_is_dev_disabled() non-static and added a call to it in amdiommu_ir_find(), but this approach seems cleaner and perhaps less likely to break if per-device busdma options are changed in the future.

Further cleanup of unionfs_unlock()

In D53079#1212688, @asomers wrote:

In D53079#1212648, @glebius wrote:

I trust Alan's expertise here. IMHO, given that this patch is analog to fusefs one, should be fine. But not expert in the area.

It's a stretch to say that I have expertise here. I've never made any changes to unionfs before.

I did post some related questions to https://reviews.freebsd.org/D52625 about both the policy of passing NULL for the thread to VOP_CLOSE and the possibility of trying to make the passing of file objects to vnode ops more consistent.
But assuming everyone's ok with still passing NULL there, I'll also update VOP_OPENCLOSE.9 to note that possibility.

Apologies for dropping this on the review after-the-fact, but I was looking over the unionfs version of the bug Alan filed (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289700), and a couple of questions jumped out at me:

I hadn't thought about it very much at all TBH, but the 2 very rough ideas I had were either to factor out the newbus walk into a common (gracefully failing) helper that could be used by both iommu_get_requester() and the sysctl handler, or to do as you suggest and change iommu_get_requester() to return an error.

Would it be better to handle the bug in the PR with a few extra checks in the calling DEVICE_SYSCTL_IOMMU code? That would also allow the sysctl to return some string in the sbuf to clearly indicate that the RID can't be determined or is N/A.

Avoid destructive copy

Oops, I didn't see this until after I wrote and tested my own version: https://reviews.freebsd.org/D47769