Hello,
On Sat, Nov 26, 2022 at 08:33:28PM +0100, Hrvoje Popovski wrote:
</snip>
> I just need to say that with all pf, pfsync and with pf_purge diffs
> after hackaton + this diff on tech@
> https://www.mail-archive.com/tech@openbsd.org/msg72582.html
> my production firewall seems stable and it wasn't without that diff
this diff still waits for OK. it makes pfsync to use
state mutex to safely dereference keys.
>
> I'm not sure if we have same diffs but even Josmar Pierri on bugs@
> https://www.mail-archive.com/bugs@openbsd.org/msg18994.html
> who had panics quite regularly with that diff on tech@ seems to have
> stable firewall now.
>
>
>
> r620-1# uvm_fault(0xffffffff82374288, 0x17, 0, 2) -> e
> kernel: page fault trap, code=0
> Stopped at pfsync_q_del+0x96: movq %rdx,0x8(%rax)
> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> *192892 19920 0 0x14000 0x200 5K softnet
> pfsync_q_del(fffffd82e8a4ce20) at pfsync_q_del+0x96
> pf_remove_state(fffffd82e8a4ce20) at pf_remove_state+0x14b
> pfsync_in_del_c(fffffd8006d843b8,c,79,0) at pfsync_in_del_c+0x6f
> pfsync_input(ffff800022d60ad8,ffff800022d60ae4,f0,2) at pfsync_input+0x33c
> ip_deliver(ffff800022d60ad8,ffff800022d60ae4,f0,2) at ip_deliver+0x113
> ipintr() at ipintr+0x69
> if_netisr(0) at if_netisr+0xea
> taskq_thread(ffff800000030000) at taskq_thread+0x100
> end trace frame: 0x0, count: 7
> https://www.openbsd.org/ddb.html describes the minimum info required in
> bug reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{5}>
>
those panics are causing me headaches. this got most-likely uncovered
by diff which adds a mutex. The mutex makes pfsync stable enough
so you can trigger unknown bugs.
thanks and
regards
sashan
