| created | 2021-06-27T09:14:27Z |
|---|---|
| begin | 2021-06-23T00:00:00Z |
| end | 2021-06-23T04:16:32Z |
| path | src/sys |
| commits | 1 |
| date | 2021-06-23T04:16:32Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/pf.c | log | diff | annotate |
| src/sys/net/pfvar.h | log | diff | annotate | |
| message |
rework pf_state_expires to avoid confusion around state->timeout. im going to make it so pf_purge_expired_states() can gather states largely without sharing a lock with pfsync or actual packet processing in pf. if pf or pfsync unlink a state while pf_purge_expired_states is looking at it, we can race with some checks and fall over a KASSERT. i'm fixing this by having the caller of pf_state_expires read state->timeout first, do it's checks, and then pass the value as an argument into pf_state_expires. this means there's a consistent view of the state->timeout variable across all the checks that pf_purge_expired_states in particular does. if pf/pfsync does change the timeout while pf_purge_expired_states is looking at it, the worst thing that happens is that it doesn't get picked as a candidate for purging in this pass and will have to wait for the next sweep. ok sashan@ as part of a bigger diff |
|||