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