Date: Mon, 02 Dec 2019 03:39:22 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 219901] [Panic] [if_bridge] panic when destroying interface on bridge over time Message-ID: <bug-219901-7501-1Gxwtm9ypA@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219901-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-219901-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219901 --- Comment #2 from Reshad Patuck <reshadpatuck1@gmail.com> --- (In reply to Bjoern A. Zeeb from comment #1) Hi, I know it has been long, but I recently have seen similar failure on 12.1 (= and I think on one of my 12.0 systems too). I do have the crash dump vmcore files if you would like me to run some other tests. This happens when I am trying to teardown the networking across multiple vi= mage jails (by calling ifconfig commands in parallel). >From the backtrace this looks specific to removing an epair from a bridge (= once again using ifconfig in parallel). I am not sure that the issue I am facing here is exactly the same as the on= e I saw when creating this issue, but it looks very similar. Here is the backtrace from kgdb for what I am seeing. I am using the latest 12.1 release and have attached an output of uname for= the exact release version. Any help either getting to a route cause or even a workaround for this woul= d be much appreciated as I have seen 6 crashes in the last week root@build-1:~ # uname -a FreeBSD build-1 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 r354729 GENERIC am= d64 (kgdb) backtrace=20 #0 __curthread () at /usr/src/sys/amd64/include/pcpu.h:234 #1 doadump (textdump=3D<optimized out>) at /usr/src/sys/kern/kern_shutdown= .c:371 #2 0xffffffff80bd01c8 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:451 #3 0xffffffff80bd0629 in vpanic (fmt=3D<optimized out>, ap=3D<optimized ou= t>) at /usr/src/sys/kern/kern_shutdown.c:877 #4 0xffffffff80bd0423 in panic (fmt=3D<unavailable>) at /usr/src/sys/kern/kern_shutdown.c:804 #5 0xffffffff810a7dcc in trap_fatal (frame=3D0xfffffe001c730380, eva=3D104= 0) at /usr/src/sys/amd64/amd64/trap.c:943 #6 0xffffffff810a7e19 in trap_pfault (frame=3D0xfffffe001c730380, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:767 #7 0xffffffff810a740f in trap (frame=3D0xfffffe001c730380) at /usr/src/sys/amd64/amd64/trap.c:443 #8 <signal handler called> #9 __mtx_lock_sleep (c=3D0xfffff80066f6fa30, v=3D<optimized out>) at /usr/src/sys/kern/kern_mutex.c:565 #10 0xffffffff82be048e in bridge_mutecaps (sc=3D0xfffff80066f6fa00) at /usr/src/sys/net/if_bridge.c:916 #11 0xffffffff82be017a in bridge_delete_member (sc=3D0xfffff80066f6fa00, bif=3D0xfffff80028463000, gone=3D1) at /usr/src/sys/net/if_bridge.c:1033 #12 0xffffffff82be07eb in bridge_ifdetach (arg=3D<optimized out>, ifp=3D0xfffff80004900800) at /usr/src/sys/net/if_bridge.c:1829 #13 0xffffffff80ccde5a in if_detach_internal (ifp=3D<optimized out>, vmove= =3D0, ifcp=3D0x0) at /usr/src/sys/net/if.c:1187 #14 0xffffffff80ccd36e in if_detach (ifp=3D0xfffff80066f6fa30) at /usr/src/sys/net/if.c:1041 #15 0xffffffff83055c4c in epair_clone_destroy (ifc=3D0xfffff800209a8300, ifp=3D0xfffff80004900800) at /usr/src/sys/net/if_epair.c:972 #16 0xffffffff80cd5b7d in if_clone_destroyif (ifc=3D0xfffff800209a8300, ifp=3D0xfffff80004900800) at /usr/src/sys/net/if_clone.c:330 #17 0xffffffff80cd5a0e in if_clone_destroy (name=3D0xfffffe001c7308c0 "epair205a") at /usr/src/sys/net/if_clone.c:288 #18 0xffffffff80cd2915 in ifioctl (so=3D0xfffff800207d3000, cmd=3D214960780= 1, data=3D0xfffffe001c7308c0 "epair205a", td=3D<optimized out>) at /usr/src/sys/net/if.c:3106 #19 0xffffffff80c3b55e in fo_ioctl (fp=3D<optimized out>, com=3D<optimized = out>, data=3D0xfffff8005f459000, active_cred=3D0x1, td=3D<optimized out>) at /usr/src/sys/sys/file.h:337 #20 kern_ioctl (td=3D0xfffff8005f459000, fd=3D<optimized out>, com=3D214960= 7801, data=3D0xfffff8005f459000 "") at /usr/src/sys/kern/sys_generic.c:804 #21 0xffffffff80c3b22d in sys_ioctl (td=3D0xfffff8005f459000, uap=3D0xfffff8005f4593c0) at /usr/src/sys/kern/sys_generic.c:712 #22 0xffffffff810a8984 in syscallenter (td=3D0xfffff8005f459000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135 #23 amd64_syscall (td=3D0xfffff8005f459000, traced=3D0) at /usr/src/sys/amd64/amd64/trap.c:1186 #24 <signal handler called> #25 0x0000000800473e4a in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffe308 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219901-7501-1Gxwtm9ypA>