Bug 213015
| Summary: | openvswitch and vnet jails - panic when bridge is destroyed and recreated | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | akoshibe | ||||||
| Component: | kern | Assignee: | Andrey V. Elsukov <ae> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Only Me | CC: | ae, bz, girgen | ||||||
| Priority: | --- | ||||||||
| Version: | 11.0-STABLE | ||||||||
| Hardware: | amd64 | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
|
Description
akoshibe
2016-09-27 04:52:04 UTC
I've hade exaclty the same problems with epair, switched to netgraph instead which has proven rock solid. I know there is a project to improve this area as well, can't remember frmo the top of my head who is working on it. Don't think it has hit the source tree yet though. For epair problems, see for example this thread: https://forums.freebsd.org/threads/31765/ If all you want is networking running in jails, I can document the procedure we use, using netgraph (not epoair). This is very solid. Epair+vimage has alsway had this problem when tearing down the jail, sadly. Palle (In reply to Palle Girgensohn from comment #1) I've noticed that I won't trigger a panic if, keeping everything else the same, I omit sending traffic (e.g. the one ping in the test script) or replace openvswitch with if_bridge. Hence, I'm also wondering if it's something about what openvswitch does with its tap interface. If there is a solid way to do jails with networking and netgraph, that is something that I would like to take a look at, and would appreciate pointers for... (In reply to Palle Girgensohn from comment #1) That forums thread is quite old; things should have improved for 11. (In reply to akoshibe from comment #2) When in your shell script does the panic happen? Do you know? I wonder if it's before the ifconfig commands. In general I wonder if the OVS buffers packets and does a deferred transmit, e.g. like the netisr; in that case on del one would have to cleanup the queue. (In reply to Bjoern A. Zeeb from comment #4) I'm suspecting that the panic occurs when I create the bridge for the second time. I'm going to try to check if that's the case later today. (In reply to Bjoern A. Zeeb from comment #3) Mmm, indeed it is. But I haven't seen that much action about epair lately, has it really been improved enough? The described problem is identical with what we experienced back then. (In reply to akoshibe from comment #5) Looking more closely, the panic is during the first time ovs-vsctl is called in the script (after a previous uneventful run). The last lines I see in dmesg prior to a panic are: epair0a: Ethernet address: 02:ff:50:00:03:0a epair0b: Ethernet address: 02:ff:a0:00:05:0b <5>epair0a: link state changed to UP <5>epair0b: link state changed to UP epair1a: Ethernet address: 02:ff:50:00:06:0a epair1b: Ethernet address: 02:ff:a0:00:07:0b <5>epair1a: link state changed to UP <5>epair1b: link state changed to UP <6>epair1a: permanently promiscuous mode enabled <6>epair0a: permanently promiscuous mode enabled tap1: Ethernet address: 00:bd:4e:02:f9:01 <5>tap1: link state changed to UP <6>tap1: changing name to 'vbr0' <6>vbr0: permanently promiscuous mode enabled and current process points to ovs-vswitchd. Created attachment 180356 [details]
test - ignore interfaces being renamed
I finally had the chance to dig around more, myself.
Open vSwitch seems to try to write something when a new switch is being created with ports. It would sometimes do so while the tap device is in the process of being renamed, and ifp->if_bpf is null.
Preventing the departure handler from setting if_bpf to null during renames stopped the panic:
Index: net/bpf.c
===================================================================
--- net/bpf.c (revision 313973)
+++ net/bpf.c (working copy)
@@ -2678,6 +2678,9 @@
struct bpf_if *bp, *bp_temp;
int nmatched = 0;
+ if (ifp->if_flags & IFF_RENAMING)
+ return;
+
BPF_LOCK();
/*
* Find matching entries in free list.
A commit references this bug: Author: ae Date: Mon Mar 13 09:04:10 UTC 2017 New revision: 315192 URL: https://svnweb.freebsd.org/changeset/base/315192 Log: Ignore ifnet renaming in the bpf ifnet departure handler. PR: 213015 MFC after: 1 week Changes: head/sys/net/bpf.c A commit references this bug: Author: ae Date: Mon Mar 20 08:10:58 UTC 2017 New revision: 315624 URL: https://svnweb.freebsd.org/changeset/base/315624 Log: MFC r315192: Ignore ifnet renaming in the bpf ifnet departure handler. PR: 213015 Changes: _U stable/11/ stable/11/sys/net/bpf.c A commit references this bug: Author: ae Date: Mon Mar 20 08:16:05 UTC 2017 New revision: 315625 URL: https://svnweb.freebsd.org/changeset/base/315625 Log: MFC r315192: Ignore ifnet renaming in the bpf ifnet departure handler. PR: 213015 Changes: _U stable/10/ stable/10/sys/net/bpf.c |
