On 07/05/19(Tue) 11:46, Hrvoje Popovski wrote: > Hi all, > > for testing MP network diffs i'm using some intrusive commands in loop > while sending traffic through openbsd box, leave loop to run and after > some time something will happen or not :) > > few days ago by accident i run same loop twice and got various panics > and page faults... with one loop everything seems fine.. > not sure if this is too aggressive and worth doing but i managed to > reproduce same panics so i'm sending report here ... > > > ddb outputs from this morning: > http://kosjenka.srce.hr/~hrvoje/zaprocvat/bridge_panic01.txt > http://kosjenka.srce.hr/~hrvoje/zaprocvat/bridge_panic02.txt
Thanks for the report. The problem isn't related to bridge(4), it is common to any cloning device. It's a race than can be triggered when two processes try to destroy the same interface at the same time. Here's where the "first" ifconfig destroy got blocked: mi_switch() at mi_switch+0x240 sleep_finish(ffff800025c47df8,1) at sleep_finish+0x81 cond_wait(ffff800025c47e78,ffffffff81a87e1a) at cond_wait+0x51 taskq_barrier(ffff800000027080) at taskq_barrier+0x99 ifq_destroy(ffff800000e11260) at ifq_destroy+0x88 if_detach(ffff800000e11000) at if_detach+0x2fc bridge_clone_destroy(ffff800000e11000) at bridge_clone_destroy+0x17b if_clone_destroy(ffff800025c480a0) at if_clone_destroy+0x117 ifioctl(fffffd887db9c1a8,80206979,ffff800025c480a0,ffff8000fffefc78) at ifioctl+0x1b3 The races exists because the second if_clone_destroy() iterates on `ifnet' and gets a reference of `ifp' while the first one is blocking, certainly on the NET_LOCK(). The easiest way to fix this problem should be certainly to serialize all clone/destroy operations. I hope this won't led us into a lock order issue.
