Page MenuHomeFreeBSD

pf: use hashalloc(9) for key, id, src-node and udp-endpoint hashes
ClosedPublic

Authored by glebius on Fri, Mar 27, 7:21 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Apr 11, 8:04 PM
Unknown Object (File)
Sat, Apr 11, 6:17 AM
Unknown Object (File)
Fri, Apr 10, 2:07 AM
Unknown Object (File)
Fri, Apr 10, 12:15 AM
Unknown Object (File)
Thu, Apr 9, 5:47 PM
Unknown Object (File)
Wed, Apr 8, 9:59 AM
Unknown Object (File)
Tue, Apr 7, 9:45 PM
Unknown Object (File)
Tue, Apr 7, 4:52 PM

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 71746
Build 68629: arc lint + arc unit

Event Timeline

glebius added inline comments.
sys/netpfil/pf/pf.c
1435

.head = HASH_HEAD_LIST is not needed, but I decided to be more explicit.

glebius retitled this revision from pf: use hashalloc(9) for key and id hashes to pf: use hashalloc(9) for key, id, src-node and udp-endpoint hashes.Sat, Mar 28, 6:59 PM
  • Extend to src-nodes and udp-endpoints hashes.
sys/netpfil/pf/pf.c
1448–1449

Initialization of .type and .head to the default values. May be omitted.

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.

In D56113#1284599, @kp wrote:

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.

That's because you have it on top of older version of D55904. In the updated version MTX_NEW is passed. For me this revision passes all pf tests.

Ah, yes, thanks!

This revision is now accepted and ready to land.Mon, Mar 30, 8:03 PM