As long as the existing test suites pass, I'm happy.

Closed by commit https://reviews.freebsd.org/rG8ef8c6abfadfc9eb0465ce57c6b09ca310415bdd

This is not correct. First, the TCP_MAXSEG set with setsockopt(2) should match TCP_MAXSEG later retrieved with getsockopt(2). It refers to configured MSS. Second, tcp_maxseg() determines current possible MSS to be used with cwnd calculations. The result of tcp_maxseg() maybe different depending on current state of SACK. Randall later added tcp_fixed_maxseg() that ignores SACK. I'd leave other congestions experts to judge which one is correct for cwnd calculations. But neither tcp_fixed_maxseg() will work correctly here, as would break setsockopt/getsockopt result.

That syntax doesn't work for me on FreeBSD console, and I know others too, so I took it for granted. I'll dig in a bit when I get back to my desk. Just to give some idea on the range of moving parts:

In D54573#1255018, @pouria wrote:

@glebius Can I commit it with a 1-week MFC?

My understanding is that the TCP MSS is the maximum number of payload bytes without any IP level or TCP level options. Are we going to change that? Then it should also apply to setsockopt(). But I don't see a reason why we should change that semantic.

In D54893#1255087, @dsl wrote:

e.g. sysctl dev.dpaa2_ni.0 is not enough?

Alan' editing.

In D54897#1255061, @kib wrote:

I think this is fine, and I have this change in some intermediate version of the patch.
But then I noted that e.g. inotify(2) is not there (unless I mistaken), so I decided that it is up to upstream to add missed syscalls, and then import a new version.
You might add inotify as well while there.

I suggest a few wording changes. Also, fork->vfork, pdfork->pdrfork, and execfd->procdescp.

In D54895#1255107, @emaste wrote:

I can implement this but we missed 22.1.x branching. I'll implement this in future when we MFV llvm 23.

We can also implement it in the copy in our tree and replace it with what ends up upstream. Most important is just to have agreement with upstream on the command-line interface so that we don't introduce a breaking change later on.

I can implement this but we missed 22.1.x branching. I'll implement this in future when we MFV llvm 23.

In D54731#1255008, @jrm wrote:

@haraldei, look at the diffs, nothing problematic stands out to me. I can do i386/amd64 build tests in about a day or so, if that's helpful. (I recently upgraded all my systems from 15 to 16-CURRENT, so all packages are rebuilding.)

In D54731#1254985, @fuz wrote:

LGTM, sorry for the delay.

Reword the unclear and long sentence.

In D54785#1255050, @markj wrote:

In D54785#1254929, @jtl wrote:

@markj Thanks for the review! Do you have any thoughts on enabling this by default right away vs. waiting a month or so?

I think you should just go for it, maybe with a long MFC period.

In D54895#1254999, @emaste wrote:

We open it in read-only mode by default so it's a bit safer, just to avoid possibly corrupting the running system.

I don't think lldb has a way that we could do something like this on the command line, but it ought to. It would be nice to support something like ssh's -o (although -o specifically is already taken) so that we could e.g. -o kernel-rw=yes or -o aslr=no.

e.g. sysctl dev.dpaa2_ni.0 is not enough?

After this lands, RFSPAWN tests can be enabled on x86 by using *fork_thread() instead of raw *rfork().

Update the rest of the divert-to test cases to exercise v6.