Hello,
On Fri, Apr 10, 2026 at 10:41:56AM +0200, Renaud Allard wrote:
> On Thu, Apr 10, 2026, Alexandr Nedvedicky wrote:
> > I think this needs to be moved to the free: goto target below.
>
> The early goto free paths (strlcpy failures) never attach a
> table, so the != NULL guard works at either location.
>
> At free: the PF_LOCK is no longer held. pfr_detach_table does
> a non-atomic refcount decrement, and all existing callers appear
> to hold PF_LOCK (pf_free_state via pf_rm_rule, pf_commit_rules,
> pf_sourcelim_rollback, etc.). Since pfr_ktable objects are
> shared globally, pf_free_state from the packet path could race
> on the same refcount.
>
> At unlock: the lock is still held, no race possible.
> But you know the locking better than me and maybe I missed
> something about the locking.
>
> Updated diff moves it to free: as you suggested.
sorry, you are absolutely right about locking. your first
version of the diff is correct.
thanks and
regards
sashan
