It seems this is not enough to prevent panics. Simple kernel module to reproduce the panic.

Document GRE-in-UDP in gre(4).

Ok. It is more flexible, but produces additional options. I think ipfw(8) is already very complex.
What if we will make "missing"+"flush" behavior as default.
It seems if user wants to create table, it is expected that later this table will be filled. So, if we are creating some table, and it is already exist, we will check that the table has the same configuration and then flush it.
If configuration is different, then we return error. What you think?

IPv6 has the same code.

I think you can add to the beginning of your ipfw rules script something like this:

ipfw -q flush
ipfw -q table all destroy

And then create needed tables and fill them.

Mark, do you suppose that this can fix some another strange panics that appear after epochification?

LGTM.

Note, that automatic loading for cxgbe can do unexpected firmware update when user does first boot.

LGTM.

I think you may find useful ipfw_pmod module too, it adds support for TCP MSS modification, but, yes, it is not related to IPv6. However, ng_tcpmss does not support TCP over IPv6, but ipfw_pmod does :)

In D19622#421205, @bz wrote:

@glebius and @hselasky rather than changing pr_drain I wondered about an eventhandler or something as that way dealing with non-protocol places such as firewalls, netisr, .. would also be possible? I think not queuing is not an option, arp queue is just another one of these places... there's more and more the longer I think about it... We'll need something to get them all (and getting the locking right).

Committed in rS345262, rS345263, rS345264, rS345274.

Remove object files. Sorry.

Fix misused ENOENT in some places.

Add missing TOK_STATES_CHUNKS token

I have no objection. AFAIR, the main goal of this change was the adding ability to extend number of entries for some tables, that have very little number of partition entries, e.g. 1 or 2.
I think if you revert this change, then you will not able to add new partitions for these tables, even if there are enough space to keep them.

Looks reasonable.

In D18904#405557, @karels wrote:

arprequest_internal would be better.