• Rebase the test after the flakyness fix.

In D53081#1212746, @markj wrote:

Do we not block at all when sending on a dgram socket and the receiver has insufficient space?

• Improve test per Alan's review.

In D53070#1212661, @mjg wrote:

This *is* used by pf_rule_counter_u64_periodic. The goal is to sum up the 32 bit values frequently enough(tm) that they don't overflow.

I trust Alan's expertise here. IMHO, given that this patch is analog to fusefs one, should be fine. But not expert in the area.

In pf_krule we got remaining:

In D53045#1212125, @ngie wrote:

The test uses OPENSSL_CONF to specify the test config file.

If it ever existed it existed in lib/libutil/login_ok.c and lib/libutil/login_times.c. Even the original import to FreeBSD does mention ignoretime.

This options plays together with times.allow and times.deny, that are still documented in the login.conf. I think deeper digging is required to see if this is indeed a cruft or actually a functional thing. If it is cruft, then documentation in login.conf on times.allow/times.deny is also cruft.

Does OpenSSL just picks up openssl.conf from current directory?

Maybe put that under DIAGNOSTIC or similar hiding ifdef? Only one or two people in the world would ever need this. Those who do, definitely would be compiling kernels.

• Add a paragraph on non-blocking mode

In D52873#1207907, @jtl wrote:

My main concern about these three revisions is that they are somewhat susceptible of remote manipulation, and that could make it easier to DoS a server. However, I view that as a tradeoff that the user needs to make, and think an appropriate release note should suffice to warn about these issues.

• Added sentence on how to set record boundaries with SOCK_SEQPACKET.

if_vmove bites again? I'm fine with adding more kludges around this problem as long as we all agree that eventually this thing needs to be removed and interfaces shall be fully destroyed and fully instantiated in a different jail.

I agree with Nick that previous comments were better. You may add assertions that match the checks in the syncookie_expand() case.

In D50825#1205589, @markj wrote:

On amd64 only, or does this work on all platforms? IIRC the amd64 flavour is a bit different, see the zpcpu_* macros in amd64/include/pcpu.h vs sys/pcpu.h.

JFYI, for counter(9) this is all what is needed:

define counter_fetch
  set $sum = 0
  set $c = (uintptr_t )$arg0 + (uintptr_t )&__pcpu[0]
  set $n = 0
  while ( $n < mp_ncpus )
    set $sum = $sum + *(uint64_t *)$c
    set $c = (uint64_t *)((char *)$c + sizeof(struct pcpu))
    set $n = $n + 1  
  end
  p/u $sum
end
document counter_fetch
display a counter_u64 value
end

I see, in

@jtl is absolutely right with this suggestion. However, what's the point on saving bits and going with uint8_t, especially with portability considerations. We aren't saving any memory here. Why not just use u_int?

• Update Intel
• Remove efi_boot check

Make it compilable on i386.

Address Benedict's review.

Thanks a lot for the fix and sorry for the breakage.

What code does call into this function with netlink argument? IMHO, this transport layer abstraction of RPC is a big code bloat where most of the code is never executed. Of course a crash if it happens needs to be fixed.