On 21.4.2021. 22:19, Alexandr Nedvedicky wrote:
> Hello,
>
> people who will be running pf(4) with bluhm's diff [1], may trip
> one of the asserts triggered by pf_state_key_link_reverse() here:
>
> 7366 void
> 7367 pf_state_key_link_reverse(struct pf_state_key *sk, struct pf_state_key
> *skrev)
> 7368 {
> 7369 /* Note that sk and skrev may be equal, then we refcount twice.
> */
> 7370 KASSERT(sk->reverse == NULL);
> 7371 KASSERT(skrev->reverse == NULL);
> 7372 sk->reverse = pf_state_key_ref(skrev);
> 7373 skrev->reverse = pf_state_key_ref(sk);
> 7374 }
>
> pf(4) currently does not provide a mutual access to state instances.
> so it may happen pf(4) will be handling more packets, which will be
> updating the same state. This is the situation of one winner and
> more losers. At this point I'm suggesting to change those asserts
> to take the race into account. diff below makes pf_state_key_link_reverse()
> happy when pf(4) runs in parallel.
>
> would it be OK to commit it once bluhm's diff [1] will be in?
>
> thanks and
> regards
> sashan
I'm running this diff with latest version of bluhm@ network parallel
diff and i'm not seeing and problems .. i'm not running pfsync ..
