Date: Mon, 19 Jan 2015 15:16:54 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195859] Reproduceble panic with VIMAGE + if_bridge Message-ID: <bug-195859-2472-nWYh6QAyZk@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-195859-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-195859-2472@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=195859 Bjoern A. Zeeb <bz@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People --- Comment #10 from Bjoern A. Zeeb <bz@FreeBSD.org> --- (In reply to Craig Rodrigues from comment #8) No, it's still used in the same jail. What seems to happen is: (a) the bridges get destroyed (all members detached, etc.), the lock gets destroyed. (b) the loopback interface in the same jail gets destroyed (c) the globally registered eventhandler in if_bridge is called for the interface (lo) disappearing. (d) we get to the point where we try to acquire the lock which we previously destroyed. Either extra checks in bridge_ifdetach() need to be implemented to catch that case (and I think that's not possible without adding extra bandaid information), or proper handling of net cloned interfaces and startup/teardown ordering needs to be implemented "as a whole". With all that the CURVET_SET/RESTORE question from comment #1 remains, as to what happens if bridge_members in the normal case reside in different VNETs (child jails)? -- 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-195859-2472-nWYh6QAyZk>