Thanks for adding this. I just had a few minor inline comments.

On amd64, translation invalidation routines don't specify whether intermediate TLB entries need to be invalidated, but on arm64 they do. Now that we have INVLPGB_FIN, I wonder if (in a separate patch certainly) it would be worth augmenting amd64's pmap_invalidate_page() etc. to specify whether intermediate entries need to be invalidated.

In D44488#1031217, @kp wrote:

In D44488#1031012, @markj wrote:

but with this change we are implicitly rewriting the source port. What explicit mechanism is the man page alluding to here?

That'd be things like rdr on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 port 8080, where we redirect incoming connections on port 80 to localhost port 8080.
When we're doing explicit rewrites it's always going to be the destination port, of course.

• Use a bitmask to record which capabilities are enabled. This is closer to what amd64 does.
• Disable hardware interrupts when enabling single-stepping. Otherwise we take a timer interrupt before single-stepping the target and don't make progress.

• Fill out more bits in ESR when pushing an exception back into the guest.
• Fix one more place that was missing an icache flush.

I've spent some time looking into the underlying, and I'm not sure that this approach (quietly rewriting the src port) is correct. The pf.conf manual page says:

In addition to modifying the address, some translation rules may modify
source or destination ports for tcp(4) or udp(4) connections; implicitly
in the case of nat rules and explicitly in the case of rdr rules.  Port
numbers are never translated with a binat rule.

but with this change we are implicitly rewriting the source port. What explicit mechanism is the man page alluding to here?

Add a variable to configure snmpd to drop privs

I don't see a reason to use atomics for the operations which happen under mca_lock. It is ok to assume that unqualified aligned pointer loads and stores are atomic; at least, we make this assumption pervasively in the kernel. It is nonetheless reasonable to use atomic_load_ptr() for the unlocked load in mca_log().

On an Altra with this patch I see:

In D45119#1029923, @kib wrote:

In D45119#1029846, @markj wrote:

In D45119#1029542, @kib wrote:

In D45119#1029511, @markj wrote:

I do not see how this solves the problem that @pho found. There, vm_map_process_deferred() was releasing writecounts, and in one case the backing vnode was doomed, so OBJ_TMPFS_VREF was clear.

Do you mean https://people.freebsd.org/~pho/stress/log/log0518.txt? I agree that this is different. But for me, log0518 states that clearing of OBJ_TMPFS_VREF and clearing of node->tn_vnode are not atomic (and really cannot be). So the assert "object with writable mappings does not have a reference" should be removed, because indeed vp might be in process of reclaim or the pointer to vp might be already invalid.

Yes, but that isn't sufficient. Consider that tmpfs_pager_writecount_recalc() will vrele() the vnode if the writecount drops to 0, which is incorrect if the TMPFS_VREF flag is already clear.

So this part should be also easy, it is enough to check that TMPFS_VREF is set before clearing it and vrele-ing the vnode. This should be correct since we observe the flag while owning the object lock.
I do not remember for sure, but I believe your patches include that chunk?

Where does the UUID come from? Is it just the build-id?

In D45119#1029542, @kib wrote:

In D45119#1029511, @markj wrote:

I do not see how this solves the problem that @pho found. There, vm_map_process_deferred() was releasing writecounts, and in one case the backing vnode was doomed, so OBJ_TMPFS_VREF was clear.

Do you mean https://people.freebsd.org/~pho/stress/log/log0518.txt? I agree that this is different. But for me, log0518 states that clearing of OBJ_TMPFS_VREF and clearing of node->tn_vnode are not atomic (and really cannot be). So the assert "object with writable mappings does not have a reference" should be removed, because indeed vp might be in process of reclaim or the pointer to vp might be already invalid.

I do not see how this solves the problem that @pho found. There, vm_map_process_deferred() was releasing writecounts, and in one case the backing vnode was doomed, so OBJ_TMPFS_VREF was clear.

Handle review comments

• Invalidate the icache after updating guest memory.
• Widen SPSR.
• Mask off extra flags in TTBR registers.

Could you please add a manual page for the new drivers, or extend the existing share/man/man4/bnxt.4?

The patch has been applied upstream: https://github.com/net-snmp/net-snmp/commit/ebb758e337a52c75a06b2448ebb44a6c78a8600e

I think this is superseded by commit e32e1a160e01a no?

IMO this patch is in the wrong order in the series. It should be first: 98% of the patch is about deduplicating implementations of uma_small_alloc(), which is a non-functional change and worthy in its own right. The rest of the series, which needs more design review and discussion before getting into detailed code review, should build on top of that.

Include missing headers sys/queue.h from vm/_vm_phys.h for TAILQ, and sys/param.h from vm/vm_phys.h for NULL so linux/io.h doesn't have to include them.

Do we have any idea what the downsides of the change are? If we make the default 64KB, then I'd expect memory usage to increase; do we have any idea what the looks like? It'd be nice to, for example, compare memory usage on a newly booted system with and without this change.

I just left some comments about style. I'm not too familiar with rman but this looks reasonable to me.

In D32308#1024957, @kevans wrote:

In D32308#1024838, @emaste wrote:

do we have user-facing documentation? maybe just expanding WITHOUT_SSP's description?

I wonder if it makes sense to add a section on stack overflow detection to security(7) would make sense

In D45049#1027045, @jrtc27 wrote:

I believe it's also legal to go and map two BARs to overlap so long as you don't try to access the overlapping range when that's the case? QEMU just maintains a list of PCI BARs and goes for the first one in the list that matches. Allocating the big chunk of MMIO memory statically at the start and just maintaining the list layered on top in PCI code as you mess with BARs seems like it would be a simple, more general fix, and should perform just fine? (Though passthrough may well be "fun" as you mention)