On Tue, Oct 02, 2018 at 01:14:16AM +0200, Alexander Bluhm wrote:
> On Thu, Sep 27, 2018 at 06:34:45PM +0200, Alexandr Nedvedicky wrote:
> > OK to pfsync change?
>
> OK bluhm@, just two style nits
>
> > + if ((e = ip_output(m, NULL, NULL, IP_RAWOUTPUT, >sc_imo,
> > + NULL,
On Thu, Sep 27, 2018 at 06:34:45PM +0200, Alexandr Nedvedicky wrote:
> OK to pfsync change?
OK bluhm@, just two style nits
> + if ((e = ip_output(m, NULL, NULL, IP_RAWOUTPUT, >sc_imo,
> + NULL, 0)) == 0)
Usually we call the error variable "error".
> + if
On 27.9.2018. 23:37, Alexandr Nedvedicky wrote:
> On Thu, Sep 27, 2018 at 11:30:09PM +0200, Hrvoje Popovski wrote:
>> On 27.9.2018. 18:34, Alexandr Nedvedicky wrote:
>>> Mentioning parallelism: there is yet another change you need to perform
>>> in order to get more pf_test() instances running.
On Thu, Sep 27, 2018 at 11:30:09PM +0200, Hrvoje Popovski wrote:
> On 27.9.2018. 18:34, Alexandr Nedvedicky wrote:
> > Mentioning parallelism: there is yet another change you need to perform
> > in order to get more pf_test() instances running. Currently there
> > is only single input task, which
Hello,
patch below is missing piece to stuff, which I commit on n2k18 [1].
Fairly quickly people, who have PF deployed with pfsync (and are
willing to experiment), discovered a panic on PF_LOCK recursion.
The recursion is identified by stack as follows:
login: panic: rw_enter: pf_lock
