Ah, yes, thanks!

I'm seeing panics with this patch ("panic: lock "pf_keyhash" 0xfffffe00e8dffff8 already initialized").
I believe the problem is that hashalloc() allocates unzero'd memory, and which leads to incorrect assertions on the lock, if LO_INITIALIZED happens to be set in lo_flags.

I've had a quick look at making pf use this, and I have a minor annoyance.

In D55558#1271287, @olivier wrote:

In D55558#1271271, @kp wrote:

I haven't debugged it any depth (and won't be able to before early next week), but the new test case fails for me:

(kp@nut)  /usr/tests/sys/netinet % sudo kyua debug carp:vrrp_preempt                                                                                                               [14:00]
net.inet.carp.preempt: 0 -> 1
net.inet.carp.preempt: 0 -> 1
	vrrp: MASTER vrid 2 prio 10 interval 100
Files left in work directory after failure: created_interfaces.lst, created_jails.lst
ifconfig: interface epair0b does not exist
ifconfig: interface epair1b does not exist
carp:vrrp_preempt  ->  failed: preemption did not affect the second interface

But it works on both my side, and on my VM lab:

olivier@workstation:/usr/tests/sys/netinet $ sudo kyua debug carp:vrrp_preempt
net.inet.carp.preempt: 0 -> 1
net.inet.carp.preempt: 0 -> 1
        vrrp: MASTER vrid 2 prio 10 interval 100
ifconfig: interface epair0b does not exist
ifconfig: interface epair1b does not exist
carp:vrrp_preempt  ->  passed

I haven't debugged it any depth (and won't be able to before early next week), but the new test case fails for me:

One small issue is that this patch claims to move these files. That's clearly unintentional. Perhaps an artefact of how it was uploaded?

This is already in the tree, as cd0169c9379c400ec75b77e87ca770e37f964276. I managed to forget to add the 'differential revision' tag, so Phabricator didn't notice.

(Not tested, but that just seems sensible.)

In D19960#1253517, @thj wrote:

I don't think there are any links with an mtu to carry 65,575, but if there
ever are I would expect to find some bugs.

I'm not sure this is sufficient. It is still possible for tcpdump to have started, but not gotten to the point of actually opening the pflog device.

In D54382#1242817, @madpilot wrote:

Forgot to add references:

[1] 9e792f7ef7298080c058fbc2d36a4e60e596dae9