On Fri, May 19, 2017 at 11:47:21PM +0200, Alexandr Nedvedicky wrote:
> would you be able to try patch below to check if it will fix pf_forward
> failures?
Yes, this fixes it. OK bluhm@
> thanks a lot
> and sorry for inconveniences
Thanks for the quick fix. And there was no inconvenience, I ha
Hello,
would you be able to try patch below to check if it will fix pf_forward
failures?
thanks a lot
and sorry for inconveniences
regards
sasha
8<---8<---8<--8<
diff -r eb40d8d52679 src/sys/net/pf.c
--- a/src/sys/net/pf.c Fri May 19 23:
Hello,
On Fri, May 19, 2017 at 06:10:54PM +0200, Alexander Bluhm wrote:
> On Mon, May 15, 2017 at 03:19:19PM +0200, Alexandr Nedvedicky wrote:
> > I'm attaching updated final patch, which accepts your suggestion.
>
> I think this broke sys/net/pf_forward.
> http://bluhm.genua.de/regress/resul
On Mon, May 15, 2017 at 03:19:19PM +0200, Alexandr Nedvedicky wrote:
> I'm attaching updated final patch, which accepts your suggestion.
I think this broke sys/net/pf_forward.
http://bluhm.genua.de/regress/results/regress.html
When backing out pf.c rev 1.1024 it works again.
I guess it is a p
On Mon, May 15, 2017 at 15:19 +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> > Now *is* the time to commit the first step, the refactoring. Once
> > that's done we can discuss the introduction of the context.
> >
> > Could you come up with such diff?
>
> first of all: I have not managed to
Hello,
> Now *is* the time to commit the first step, the refactoring. Once
> that's done we can discuss the introduction of the context.
>
> Could you come up with such diff?
first of all: I have not managed to finish the re-factoring step yet, work
is still in progress. I stole some cy
On 28/03/17(Tue) 13:02, Alexandr Nedvedicky wrote:
> [...]
> >
> > - s/test_status/action/ as it's done everywhere else?
>
> I've opted to test_status, because it's something different to 'action'
> as we use it in current code.
I agree with you for test_status. What about naming the
;PF_TEST_* values so that it's grep'able;
this is the 'edited' diff to highlight the place, which your comment is
related to. It shows the change to patch I've sent in earlier mail [1].
[1]
http://openbsd-archive.7691.n7.nabble.com/pf-percpu-anchor-stacks-tt3149
On Fri, Mar 24, 2017 at 12:19 +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> I'm attaching patch, which removes stack-as-a-global variable.
> it's updated patch [1] to current tree.
>
> sorry for being pushy advocating my old, rusty patch.
>
I think your diff is the way to go indeed. If we can
Hello,
I'm attaching patch, which removes stack-as-a-global variable.
it's updated patch [1] to current tree.
sorry for being pushy advocating my old, rusty patch.
thanks and
regards
sasha
[1]
http://openbsd-archive.7691.n7.nabble.com/Re-PF-SMP-making-anchor-stack-multithreaded-tt275915.html#n
Hello,
I've sent different patch [1], which was touching same functions some time ago.
The old patch [1] basically splits pf_test_rule() to two functions:
pf_test_rule()
pf_match_rule(), which walks anchor stack recursively. the recursion depth
is limited to 64.
the memory foot print
Hi,
to step into and out of pf(4) anchors, pf(4) uses a temporary stack
that is a global variable. Now once we run pf_test_rule() in parallel
and an anchor is evaluated in parallel, the global stack would be used
concurrently, which can lead to panics. To solve this issue this diff
allocates a p
12 matches
Mail list logo