I share kib's curiosity, but it clearly works, so LGTM. Nice find!

Thank you for asking, but I didn't actually do the last update. @jasone did it, but had to revert it. I simply un-reverted his work.

• remove DT_CLOSE_HANG, which never happens on FreeBSD

• rebase onto D41173; store flags in dt_proc

In light of @hselasky's untimely departure, would someone on network like to review this, or suggest another reviewer?

• fix comment style

What do you think, @markj?

The DTrace test suite had fewer failures with this change. They were not fixed by this change; they're just unreliable.

• wordsmith comment

This needs a change in etc/mtree/BSD.tests.dist and perhaps ObsoleteFiles.inc.

In D40260#919297, @emaste wrote:

I have no objection to this approach (but have not reviewed the diff in detail yet).

Thank you both for the feedback. I like the idea of using OpenBSD as an upstream, but that would take a lot more time than I have right now. (Most or all of my FreeBSD time is on Dell's clock.)

I think the best approach would be to import through the vendor branch and put it in contrib/cron, and altering the makefiles to contrib/cron instead. The vendor branch provides a better degree of maintainability.

please add the CID to the commit message
(unless this is not from Coverity Scan's FreeBSD report)

It's not clear to me whether this is actually possible or just theoretical.

Common practice for attributing the submitter with git is:

In D37257#848954, @asomers wrote:

Well, it isn't ideal. But it's certainly much better than it used to be, and the ZFS tests are much too big to shoot for "ideal".

@asomers What do you think?

• Fix the tests so they actually pass

Upload the whole diff.

• Don't use log_must in cleanup.
• Invert the test for dump devices in lieu of atf_expect_fail.

Would someone kindly make D35635 and D35636 public, now that they're committed?

@markj Do the tests with largepagesize even make sense when superpages are disabled? I suppose not, but they're also harmless.

define a way to limit mbuf cluster allocations to n in a code section

Why is this necessary? Why can't we let the driver allocate all available mbufs?

Because we want to avoid a situation where we exhaust all of our preallocated mbufs to fill populate a single ring. That's the reason we preallocate as much as we do today.

How do multi-queue NICs behave when some rx rings are empty? If a packet arrives on an empty rx ring, does the packet get dropped, or does it get queued to a different rx ring?

I've always assumed that the packet would get dropped if the ring to which it's steered doesn't have any available buffer space. That might not be true for all devices, but I wouldn't want to rely on that.