Well, the master/server terminology is used
in other places, such as nfsd(8).
The terminology must be short enough that
it is displayed correctly by "ps". I think
"controlling server" would get truncated.
(This is the man page, but it needs to be
consistent with what the daemon does.)

This version gets rid of the pre-1.1.1 calls.
It also fixes a typo where I used > instead
of >= for the OPENSSL_VERSION_NUMBER.

In D40275#918519, @emaste wrote:

Could just delete the < 0x10100000L cases, since we have no need to support past-EOL OpenSSL.

I installed openssl31 via ports and did builds
using that with OPENSSL_NO_DEPRECATED_...
and found a few more.

Looks fine to me. I'll wait to hear from mav@
w.r.t. which one of us will commit it.

The "int ret = 1;" appears to still be in the patch.
I suspect that is just uploading the wrong version.
Trivial to fix during commit.

Except for the minor nit that "ret" no longer
does anything and can be removed, it
looks fine to me now.

Yes. The other nfs daemons were converted to master/server and,
at the time, that seemed to be considered appropriate.
This change makes nfsuserd do the same.

Made a couple of inline suggestions, but the code does
look correct to me.
I assume you do not have src commit bit, given your login name?

Looks ok to me. Just fyi, using xdrproc_t outside the kernel is
always a bit sketchy, since the functions have variable
numbers of arguments and the typedef is a non-typedef.

In D39419#898849, @rmacklem wrote:

danfe@ reported a problem via email where rlimit
resulted in an empty file. I think this is due to the
use of SSIZE_MAX for the length and then checking
it with a call to vn_rlimit_fsize().

I think a patch like this (basically cloned from
vn_generic_copy_file-range() is needed):

• zfs_vnops_os.c.sav 2023-04-10 08:01:05.905906000 -0700

+++ zfs_vnops_os.c 2023-04-10 08:14:40.563743000 -0700
@@ -6242,7 +6242,8 @@ zfs_freebsd_copy_file_range(struct vop_copy_file_range

	struct mount *mp;
	struct uio io;
	int error;

• uint64_t len = *ap->a_lenp;

+ uint64_t len;
+ ssize_t r = 0;

	/*
	 * TODO: If offset/length is not aligned to recordsize, use

@@ -6280,9 +6281,14 @@ zfs_freebsd_copy_file_range(struct vop_copy_file_range

	io.uio_offset = *ap->a_outoffp;
	io.uio_resid = *ap->a_lenp;

• error = vn_rlimit_fsize(outvp, &io, ap->a_fsizetd);

+ error = vn_rlimit_fsizex(outvp, &io, 0, &r, ap->a_fsize_td);

Oops, typo. It should be ap->a_fsizetd and not ap->a_fsize_td.

danfe@ reported a problem via email where rlimit
resulted in an empty file. I think this is due to the
use of SSIZE_MAX for the length and then checking
it with a call to vn_rlimit_fsize().

Made the changes suggested by karels@.

In D39441#898170, @markj wrote:

I don't understand what problem this is solving. Why is it so important to avoid setting *mpp in the failure case that we need to add a new flag?

LGTM. mjg@ can decide if he needs this for his
patch against zfs_copy_file_range().

In D39419#897831, @kib wrote:

In D39419#897830, @rmacklem wrote:

A little off topic, but would it make sense to add
"lktype" arguments to vn_lock_pair() so that it can
optionally acquire LK_SHARED vnode locks?

I did not initially because there are possible complications with LK_SHARED and recursion. What is your scenario where vn_lock_pair() LK_SHARED is useful?

A little off topic, but would it make sense to add
"lktype" arguments to vn_lock_pair() so that it can
optionally acquire LK_SHARED vnode locks?

LGTM

In D39419#897434, @pjd wrote:

We shouldn't make the code more complex and less readable just to optimize for some rare edge cases. If someone disables block cloning, they are most likely not too concerned with performance and trying to avoid an extra vnode lock at the expense of code readability is, in my opinion, the wrong approach.

Well I know nothing about ZFS, but while doing this I learned that block cloning is not enabled
by default. I suspect many other ZFS users are like me and would not know that enabling
block cloning was needed for performance (or even how to enable it). I assume there is a
reason it is not always enabled?
--> At this time, I don't think block cloning being disabled is a rare corner case.

You might find these little programs useful for testing.
(I realized my only ZFS setup doesn't do block whatever,
so I can only test the fallback to vn_generic_copy_file_range().)

Oops, I missed the reviewed by pauamma (manpages),
since it happened just when I did the commit.