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)

In D40676#1027000, @gallatin wrote:

After this change, ktrace output is littered with 'CAP system call not allowed: $SYSCALL' on systems w/o capsicum enabled, which is confusing and distracting. Can this please be reverted to behave without CAP output for systems w/o capsicum ?

Apply Domagoj's suggestion

In D44483#1023820, @domagoj.stolfa_gmail.com wrote:

I ran the tests with this applied on amd64, had a few kmods load/unload concurrently for a while and looked through the concurrency around the patching code. Everything seems to work fine on my end.

• Rebase.
• Remove license boilerplate, just keep SPDX and copyright lines.
• Fix a problem with DTRACE_PROBE which uses function-static probe structure definitions. To reference them from inline asm, we need to make the structure an input operand since we don't know the symbol name.
• Rename some constants to improve consistency.
• Work around a clang bug/limitation on i386 wherein I can't use the "i" constraint with a global variable for some reason. This works perfectly well if I just reference the symbol directly, so I'm not sure why the backend is rejecting it. Happily, there is an MD constraint ("Ws") which empirically has the behaviour I want.

Before pushing, I'll split this into two commits, one moving MD code into amd64/ and the other adding the arm64 bits.

Apply suggestions from jhb.