We should loop jrtc27 and maybe someone from srcmgr into this

I see these errors under low loads, and not always as "1 [mu]secs have passed":

I'm not convinced by the rationale here -- it seems to me that the stronger argument is "processing tx completions frees up space on the tx ring, which we might want when we respond to packets which we received". But the change itself seems reasonable.

I got another naive benchmark. It exercises situation when we create as much as possible connections from us to a single peer:port eventually running out of ports. This exercises the worst case of the cycle in in_pcb_lport_dest(), which at the end of the test is executed for 10^4 times to find a port. While the cycle itself is not optimized at all, on a virtual machine with 8 CPUs the test passes 6-7 times faster than before the change.

Apply suggestions from @des and @jilles.

• Remove redundant SRCS entry added in original diff.
• Add MK_USB == no entries to OptionalObsoleteFiles.inc .

The commit message refers to critical sections, but in fact counter_{enter,exit} are no-ops everywhere except powerpc, and somehow I doubt ENA will ever run on powerpcs. So the win here isn't about critical sections; it's just about reducing the number of atomic operations.

Simplify per review feedback

Link to more report enties and sort

Address review: use explicit 'ctrspec != NULL' in rapl_allocate_pmc (mhorne, style(9)).

remark considered

jhb's changes

Having just hit submit... I wonder if we want to spend the available bit in EXTERR_CAT_SRC_MASK on in-tree vs out of tree or maybe just make pre-pending sys/ a legacy category source thing.

I think I want to refactor cat_to_filename() to take a buffer and to handle the selective prepending of sys/, perhaps bumping the uexterr_gettext ABI. It's fine for in-tree code, but definitely wrong for out of tree modules.

This addresses an issue I realized during Kirk's talk at BSDCan. In the existing model, it's quite hard to support third-party modules and even in-tree modules for downstreams would require reserving a portion of the identifier space. This approach adds cost to the EXTERROR_VERBOSE reporting path, but significantly decouples the kernel and libc. I'm not sure I'd want to go as far moving entirely to dynamic, but it's probably not a problem in practice.

In D56165#1334631, @kib wrote:

BTW, what prevents a malicious userspace to try to sneak a mount with a type outside the allowed list after the check, but before the mount?

• Address comments

Great! Thanks, Vladlen!

Address feedback

Expand __uint64ptr_t to spares