On Monday, 13 August 2018 15:22:33 CEST Kristof Provost wrote:
> > 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 jus
On Tuesday, 14 August 2018 01:32:17 CEST Kajetan Staszkiewicz wrote:
> > > There are some more issues I found around pf_map_addr. Some of them I
> > > mentioned in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229092.
> > > Some
> > > more came out while working on this least-states loadbalanc
On Tuesday, 14 August 2018 15:44:52 CEST Ermal Luçi wrote:
> If you really want to spend time on it, the best option is to pull out the
> pool concept used by the rules/nat... and manage it outside of the
> rules/states but in its own module referenced by the former ones.
Do you mean as separate
(sorry for the top post)
If you really want to spend time on it, the best option is to pull out the
pool concept used by the rules/nat... and manage it outside of the
rules/states but in its own module referenced by the former ones.
This would allow extensibility and propper reasoning about it.
On Tuesday, 14 August 2018 16:15:48 CEST Kristof Provost wrote:
> On 14 Aug 2018, at 0:32, Kajetan Staszkiewicz wrote:
> > On Monday, 13 August 2018 17:59:15 CEST Kristof Provost wrote:
> > How about this?
> >
> > https://github.com/innogames/freebsd/commit/
> > d44a0d9487285fac8ed1d7372cc99cca83f
On 14 Aug 2018, at 0:32, Kajetan Staszkiewicz wrote:
On Monday, 13 August 2018 17:59:15 CEST Kristof Provost wrote:
How about this?
https://github.com/innogames/freebsd/commit/
d44a0d9487285fac8ed1d7372cc99cca83f616e6
That looks good to me.
There’s a few minor issues, things like inconsistent
On Monday, 13 August 2018 17:59:15 CEST Kristof Provost wrote:
> pf keeps rules around until there are no more states left referencing the
> rule. Look at pf_commit_rules(): The old rules are unlinked rather than
> removed. They’re kept on the V_pf_unlinked rules list. Every so often pf
> runs thr
On 13 Aug 2018, at 17:06, Kajetan Staszkiewicz wrote:
> On Monday, 13 August 2018 15:22:33 CEST Kristof Provost wrote:
>> rules (and associated tables) won’t just go away while there’s still
>> state,
>
> This is mostly what I wanted to ask about in this message. How is it ensured
> that table and
On Monday, 13 August 2018 15:22:33 CEST Kristof Provost wrote:
> > 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_R
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 o
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
11 matches
Mail list logo
