No problem Ed. Hope you enjoyed your vacation.
The code changes are pretty straightforward. I left
them in the style consistent with the rest of the code.
(Using "int"s instead of "bool"s for example.)

I have made the changes suggested by Alexander Ziaee to the
man pages, although I cannot update the diff here.

Ed, maybe you can take a look at the source changes?
The man page changes have already been reviewed.
I can update those and I am willing to commit these
once you've taken a look at them.

If you are agreeable to my version of the length formula,
I will update the patch with that and checks for NULL
return for both strdup() and malloc().

I did take a quick look at the Linux code and it
appears to be completely different to me, so I
don't think trying to convert it makes sense, at
least for now.

Used strdup() to copy the options into a malloc'd area,
as suggested by mav@. This makes sense, since a sharenfs
with many semicolons could be much larger than an
option list.

This version ignores whitespace only semicolon separated
option sets. I decided that allowing the "only whitespace
case" which generates a line with default options (which
is read/write to the world) did not make sense when other
option sets are being specified for other hosts/networks.

I've made some inline comments, but it looks generally ok to me.
All the man page updates require a change to the date (.Dd line)
and manpages should be asked for a group review.

I believe so, yes.

Made the changes suggested by kib@.

In D44906#1023894, @olce wrote:

In D44906#1023893, @markj wrote:

Oh hmm, not unrelated, but at a glance I think it is superseded by the privport check. That is, all code paths which lead there first have to go through the privport check. But I could be wrong about this.

It feels like NFS_REQRSVPORT is older but apparently it was introduced by the same (initial) commit as the if (nfs_privport ... check (9ec7b004d0edb). Maybe replacing NFS_REQRSVPORT by a runtime check for nfs_privport would make sense, but I don't really know this code. It may be instead that the code under NFS_REQRSVPORT is redundant, I'm not sure either. In any case, this would be a separate change.

lgtm. I cannot recall if there is any man page change
needed for this?

markj@ has a better patch in D44614.

I made a couple of comments, but feel free to ignore
them, since I think the patch is fine without the changes.

In D44499#1015512, @markj wrote:

I'd somewhat prefer to make this more prominent, having its own paragraph in the description section. I understand that the problem at hand is a natural consequence of how exports(5) works, but it's really easy for someone new to NFS to miss that they can't "safely" export a single subdirectory from a local filesystem on the server.

Made the changes suggested by emaste@.

This version looks fine to me. I'll let you decide whether or
not to leave the TCP check in.

In D44395#1012518, @wollman wrote:

Very minor comment: there should be markup for sysctl variables, but I haven't checked another manual page to be sure which one we're using. (My gut says .Li would be the expected formatting.)

This version has Mike Karel's suggested change.

va_holey may be the way to go for FreeBSD15, so long as
it is easy to calculate. Having a file system do something
akin to Seek_Hole in VOP_GETATTR() would defeat the purpose.

Updated the comment as suggested by kib@.

In D44002#1009718, @jhb wrote:

In D44002#1006603, @rmacklem wrote:

Hmm. Sounds like it should only be enabled if TLS is
not enabled?
For the TLS case, the receive code in clnt_vc.c does
upcalls to userland for non-application data records
and these are handled by the OpenSSL library using
a SSL_read() call.

No, it's fine to enable if TLS is enabled, but we do want to enable TLS first to give TLS offload priority over DDP.
You can still use DDP for data copied out to userspace, it's just not as useful an optimization in that case.

This patch would enable it before TLS unconditionally,
I think?

Yes.

If you look at clnt_rc.c, you'll find the rpctls_connect()
call right after the clnt_vc_create() call. That is what enables
the ktls via an upcall to the daemon that does a SSL_connect().
It sounds like that is where the socket option should be set?

Yes, for the client I can move it back to where it was before, but leave off the CLSET_DDP complexity.

Yes, that sounds fine to me.