Page MenuHomeFreeBSD

pf: Do not hold PF_RULES_RLOCK while processing Ethernet rules
ClosedPublic

Authored by kp on Aug 31 2021, 8:24 AM.
Tags
None
Referenced Files
F170810499: D31739.diff
Sun, Sep 6, 6:57 PM
F170676252: D31739.diff
Sat, Sep 5, 11:33 PM
Unknown Object (File)
Sat, Sep 5, 7:37 AM
Unknown Object (File)
Fri, Sep 4, 7:36 AM
Unknown Object (File)
Thu, Sep 3, 6:38 PM
Unknown Object (File)
Thu, Sep 3, 2:29 PM
Unknown Object (File)
Thu, Sep 3, 12:30 PM
Unknown Object (File)
Thu, Sep 3, 6:34 AM

Details

Summary

Avoid the overhead of acquiring a (read) RULES lock when processing the
Ethernet rules.
We can get away with that because when rules are modified they're staged
in V_pf_keth_inactive. We take care to ensure the swap to V_pf_keth is
atomic, so that pf_test_eth_rule() always sees either the old rules, or
the new ruleset.

We need to take care not to delete the old ruleset until we're sure no
pf_test_eth_rule() is still running with those. We accomplish that by
using NET_EPOCH_CALL() to actually free the old rules.

Sponsored by: Rubicon Communications, LLC ("Netgate")

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 41833
Build 38721: arc lint + arc unit

Event Timeline

Why the use of ck_* instead of atomic_*?

In D31739#776252, @mjg wrote:

Why the use of ck_* instead of atomic_*?

That'd probably work too, but we typically use the ck_* functions in combination with epoch. For example, in ifnet_byindex() or prison_ip_check().

This revision was not accepted when it landed; it landed in state Needs Review.Mar 2 2022, 4:01 PM
This revision was automatically updated to reflect the committed changes.