pf tables locking

[Kristof Provost]

On 13 Aug 2018, at 0:09, Kajetan Staszkiewicz wrote:
> Hello group,
>
> Can anybody help me iwth pf_table.c and all operations on tables, 
> especially
> pfr_update_stats? I'm working on implementing stats for redirection 
> targets,
> that is for nat or route-to.
>
> I'm going through the code and I've found out that many table-related 
> function
> are guarded by lock on pf ruleset. But that is not true for 
> pfr_update_stats.
> This function is called from pf_test only after PF_RULES_RUNLOCK().
>
I think you’re right, this does look wrong.

It’s very unlikely that this will actually lead to a crash, because 
rules (and associated tables) won’t just go away while there’s still 
state, but we could theoretically lose memory (in the pfrke_counters 
allocation), and miscount.

I don’t want to re-take the rules lock for this, so my current 
thinking is that the best approach would be to already get rid of the 
potential memory leak by just always allocating the pfrke_counters when 
the table is created (i.e. when the rule is first set). That might waste 
a little memory if we didn’t need it, but it should simplify things a 
bit.

We can resolve the counting issue by using the counter_u64_*() functions 
for them. We should be able to get away with not locking this.

Regards,
Kristof