Looks good to me aside from the comment.

Upon resume, schedule harvesting further in the future.

Fix a compile error

This looks like it's really testing the host's (cross-)build environment. That seems useful, but it's not the same as testing the installation itself, e.g., a test could invoke cc to compile this file or something similar and verify that it succeeded. Should we do both? Is there some reason this test on its own is sufficient?

Approved

In D53817#1229564, @brooks wrote:

In D53817#1229561, @markj wrote:

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

Right now vm_offset_t is inconsistent and sometimes equivalent to a ptraddr_t and sometimes to a uintptr_t. In CheriBSD we've converted a significant number of vm_offset_t's to a new vm_pointer_t because we need provenance preservation. I think @jhb wants to convert many of those into void *, but I'm a little unclear on the overalls scope. @alfredo.mazzinghi_cl.cam.ac.uk thinks we do end up with vm_pointer_t at least for a while as too much math is done on those for using void * to be comfortable.

In D53722#1226796, @andrew wrote:

Having talked to a Linux dev who is familiar with the kvm code I think we need to:

1. ensure all VCPUs are stopped

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

In D52968#1225882, @jbo wrote:

In D52968#1225880, @markj wrote:

Well, that commit is a random whitespace change... and the fix for the deadlock is not in stable/14 at all. I will try to backport it if you can test the resulting patch.

I could have sworn I saw this patch being MFC'd into stable/14...
Guessing I'm just having a bad day - apologies for the noise then :/

I will glady test any backported patch.

In D53657#1229282, @des wrote:

Needs tests.

In D53805#1229199, @cy wrote:

In D53805#1228994, @markj wrote:

In D53805#1228989, @cy wrote:

Rather than set IPFERROR within the function we return a return code and let the caller set the IPFERROR. Do you mind if I take this and flesh it out a bit?

Please go ahead!

Would you mind if the review will include the three commits (squashed) required to implement the ipfilter and ipnat verifications? Context matters.

In D53805#1228989, @cy wrote:

Rather than set IPFERROR within the function we return a return code and let the caller set the IPFERROR. Do you mind if I take this and flesh it out a bit?

This looks ok to me with Ed's suggestion applied.

Looks good overall.

usr.bin/procstat/procstat_rlimit.c should be updated too.

Approved

Seems ok, this is really just a Tested-by: markj

This won't preserve symlinks. That probably won't hurt too much.

We should really just do this in a central place in vmimage.subr, but that can be a separate change.

Fix the comment.

• Add a comment.
• Acquire the kqueue lock earlier if we're activating the knote, otherwise we will pick up and drop the kqueue lock twice in a row.

Approved

In D53784#1228124, @fuz wrote:

In D53784#1228082, @markj wrote:

Presumably this should be submitted upstream as well: https://mandoc.bsd.lv/

I think mdoc.7 needs to be updated too.

I'm ok with this landing in the meantime if it makes life easier.

The plan is to proceed like with D47284, that is, put the bandaid in right now and report it upstream.

In D53785#1228127, @lwhsu wrote:

Is this list including the lurkers or they are all full srcmgr?
Asking because this is not sync'd with https://www.freebsd.org/administration/#t-srcmgr

Presumably this should be submitted upstream as well: https://mandoc.bsd.lv/

Approved.

Update rc.conf.5 too

Ok, so PlotSet() sets pl->data[j * pl->width + x] |= val where 0<=val<MAX_DS. So your assertion is true, but only because MAX_DS is a power of 2.

In D53747#1227297, @0mp wrote:

Looks OK.

Would you also have the time to document NAME_audit_user and audit_user in rc.conf(5)? In particular, the difference between command-based and function-based services is worth documenting.