In D8904#184430, @hrs wrote:

The cause is that the prefix route was removed by in_scrubprefix() in the PRC_IFDOWN handler and never reinstalled upon PRC_IFUP because the reinstallation is done only for ifa passed to SIOCAIFADDR. Just calling if_up(ifp) looks too heavy to me because it causes extra pr_ctlinput() calls of each protocol, not only inetdomain, in order to recover the routes. What do you think about adding reinstalltion of the prefix routes in the protocol specific PRC_IFUP handler instead?

It's probably better to call sysctl_ctx_init for the stat_ctx, when priv->sysctl is assigned. Or just moving the ctx_inits and sysctl assignment to common place. TAILQ requires explicit initialization, and we normally treat sysctl_ctx as opaque struct in drivers.

In D8789#183254, @kib wrote:

In D8789#183250, @kib wrote:

In D8789#183231, @sepherosa_gmail.com wrote:

In D8789#183203, @kib wrote:

So you did not added support to 32bit libc. Why ?

It currently requires mulq, which is not available on 32 bits system.

The code doesn't require 128bit multiplication support, it is useful for optimization but not critical. It is possible to express the same calculation using the big numbers multiplication (or, if you prefer it, a term from russian elementary school, 'multiplication in column').

If 64bit values are X=a*g+b and Y=c*g+d, where g is 2^32, a,b, and c,d are 32bit high and low words of the corresponding 64bit values, then X*Y = a*c*g*g + (a*d + b*c)*g + b*d. You need to care about the carry bit. It is slightly more cumbersome then mulq, but not too complicated.

You could copy/paste the code from contrib/libcompiler_rt/lib/builtins/multi3.c, the __mulddi3() function.

In D8789#183203, @kib wrote:

So you did not added support to 32bit libc. Why ?

Use d_open to prevent write mmap, pointed out by kib

Add compiler fence through atomic_*_acq, suggested by kib

Fix reversed logic

Fallback to other timecounter's tc_get_timecount is not a good idea.

In D8656#179616, @jhb wrote:

If you don't need the timeout, that is fine to remove of course. If you need the timeout for other reasons, see if rS309148 fixes the panics for you.

Allow double-orphan on destroy path. Make the life easier for xact API consumers.

The try lock scheme you have used will cause two types of issues:

In D8409#175275, @jhb wrote:

This looks fine. Note that there is some existing code this somewhat duplicates. For example, the ACPI Host-PCI bridge driver also parses _CRS to determine valid ranges. It uses the pcib_host_res_* API to add those ranges to a list that it then iterates on allocation requests. I'm not sure if does the same trick of preferring > 4G ranges for 64-bit BARs (though if pcib_host_res_*() would otherwise work for you I'd be fine with fixing it to do the same).

Ship it!

Ship it!