On 10.8.2022. 15:44, Vitaliy Makkoveev wrote: > On Wed, Aug 10, 2022 at 12:52:06AM +0200, Hrvoje Popovski wrote: >> On 9.8.2022. 22:22, Vitaliy Makkoveev wrote: >>> Hi, >>> >>> The kernel lock within pflow_output_process() doesn't help because the >>> following sosend() has sleep points. So, at least pflow_clone_destroy() >>> should wait until pflow_output_process() finished. We should use >>> taskq_del_barrier(9) instead of task_del(9). >>> >>> Also we need to unlink dying pflow(4) interface from the stack before >>> start destruction. >>> >>> This diff should help. Please keep in mind, this diff is incomplete, >>> because it doesn't fix the race between pflowioctl() and >>> pflow_output_process(). This race is much more complicated, because we >>> need to introduce the new lock to protect `so' and take it before call >>> sosend(), but the sosend() takes netlock, which is taken before >>> pflowioctl() where we modify `so'. This introduces re-locking games to >>> pflowioctl() path, I so want to make this with separate diff, because >>> this potential panic was not triggered. >>> >> Hi, >> >> with this diff I'm getting this protection fault trap >> > taskq_del_barrier(9) has a bug and doesn't work as expected. This diff > uses taskq_barrier(9). > > According private Hrvoje report it fixes the problem.
Hi, I'm was running ifconfig pflow0 destroy sleep 120 sh /etc/netstart pflow0 sleep 120 whole night and firewall didn't break. Without this diff if I run ifconfig pflow0 destroy and firewall is under pressure box got kernel fault trap immediately
