Approved by: bz (co-mentor)

Address kp's catch of the SYSCTL_OPAQUE size.

Thanks a lot for reviewing! Much appreciated!

In D22334#488613, @ae wrote:

The most of code that uses m_pullup() does check first, that the call is needed. Do you think that now it is considered as light enough, to do not check this?

Rename FOO_<> to FOO.<> as requested by @imp.

libkvm does know about VNETs (see kvm_private.c / kvm_vnet.c) as much as it knows about DPCPU. I seem to remember however it needs something selected, such as a PID or curthread from the dump, as it gets VNET information from there. This is probably something that should be generally fixed for netstat and not just for mrouting, though I am sure I tested that on a core dump back then. People may have broken it or the netstat parts were never merged.

I'd like to commit the main part of the change with(out) the two changes I commented on the next 24 hours.
Does anyone want to have a look?

In general I really like the changes. I've not looked into the large chunks of sysctls / UDP / TCP in too much detail. I'll try to do them based on their individual git changes the next days (at least sysctl and UDP). Hope someone else will do the TCP bits.

All your "stub functions" return (0), when in fact they probably should return an error? Or what happens if someone tries to set a (hw)breakpoint on these architectures?

If the netisr logic is restored I am happy with this. I'd commit the IPv6 "style" changes separately though.

I guess given the frag6_destroy() is only in my local tree still, this should be fine to go and I'll fill the vnet check for frag6 in later (as you indicated), when we are no longer leaking frag6 data.

I left you a sample change which should be good enough for the IPv4 frag reassembly to no longer trip over VNET shutdown problems and is independent on when things will happen and independent on any SI_SUB_* ordering.

I am sorry, was I not clear enough in email that we actually need none of this changed (neither the previous commits nor any of this) in order to solve your original problem? Can we please try not to further touch what was a working system (or complicate it more).

In general I like the change very much. See the minor comment for sanity checks in the internal implementation.

If you are happy, just go ahead and commit it. I didn't boot it.

Okay. I see why the vnet0 state is not updated. I'll take that as a different problem as it requires a bit of trickyness as it goes through the code module loading also uses.

In D19622#439705, @jtl wrote:

In the interests of avoiding discussion fragmentation, I am adding the feedback from the transport working group meeting today.

@hselasky raised this on the working group call and solicited feedback. The strong (seemingly-unanimous) feedback on the call was that we should not discard fragments when the associated interface goes away. Some points that were raised include:

• Systems which have multiple interfaces can receive different fragments over different interfaces. Therefore, the other fragments may still arrive over other interfaces.
• Systems with flapping interfaces may receive fragments after the interface recovers.
• It is not unheard of for systems to queue fragments for multiple seconds. Therefore, it is possible that the fragments will arrive once connectivity is restored and/or rerouted.

It was the strong feeling of the participants on the call that this problem should be solved in a way which preserves the fragments on the queue. Some suggestions included:

• At the time of enqueueing, copying the information from the ifnet pointer which is necessary to process the packet. Save this information, rather than the ifnet pointer.
• When an interface goes away, clear the ifnet pointer from the fragments on the queue. Skip processing steps which depend on this information (which @hselasky described as incrementing interface statistics and sending an error response when a fragment is dropped).

In general this seems good.

In D19111#476113, @glebius wrote:

I'd like to go forward with this change. It will bring a number of new epoch recursions, that don't exist today, but I want to resolve them separately, one per subsystem, otherwise the changeset will get bigger and more messy. I need your review, guys. :)

This may sound like a pain but as you already say in your message, this is two changes .. First .. Second ..
Can you split them up into such? First should be really easy to review and second should then be straight forward as well by itself.