On Wed, Apr 15, 2026 at 09:55:23AM +0200, Alexandr Nedvedicky wrote:
>     it all makes sense however the pf(4) is not there yet. PF_LOCK()
>     is not going away anytime soon. The lock protects those tables
>     packet may modify on its journey through pf_test():
>
>       - IP address tables (see overload action in pf.conf(5))
>
>       - source IP address tables (see max-src-nddes, max-src-states,
>           source limiter in pf.conf(5))
>
>       - and state table, however this can be in theory moved out
>         from PF_LOCK() scope, because it has its own RW-lock.
>
>     The good time to land your diff will be once there will be a plan
>     how to split the PF_LOCK() to 'smaller locks'. And here IMO are
>     the complications which come from pf_ioctl().

Understood. Parking the rule refcount diff. It is the right primitive
for the lifetime question on its own, but landing it before the
PF_LOCK split is planned is the wrong order of operations.

> If you are really interested to dive into this I can provide more
> details. Just let me know.

Yes please. I would like to understand the broader PF_LOCK split
plan and where pf_ioctl() makes it complicated. If you can sketch
which of the three subsystems (overload tables, source-IP tables,
state table) needs its own protection first, and what the ioctl
complications look like in practice, I can read that code with the
right context and figure out what is useful to work on.

I have time and I would rather contribute one useful piece of the
larger arc than push a diff that lands at the wrong moment.

thanks
pierre