orange-opensource / oko Goto Github PK

root@ovn:/etc/openvswitch# ovn-docker-overlay-driver --monitor
ovs-vsctl: no key "ovn-nb" in Open_vSwitch record "." column external_ids
Traceback (most recent call last):
File "/usr/bin/ovn-docker-overlay-driver", line 441, in
prepare()
File "/usr/bin/ovn-docker-overlay-driver", line 103, in prepare
ovn_init_overlay()
File "/usr/bin/ovn-docker-overlay-driver", line 87, in ovn_init_overlay
"external_ids:ovn-nb").strip('"')
File "/usr/bin/ovn-docker-overlay-driver", line 62, in ovs_vsctl
return call_prog("ovs-vsctl", list(args))
File "/usr/bin/ovn-docker-overlay-driver", line 58, in call_prog
return call_popen(cmd)
File "/usr/bin/ovn-docker-overlay-driver", line 48, in call_popen
raise RuntimeError("Fatal error executing %s" % (cmd))
RuntimeError: Fatal error executing ['ovs-vsctl', '--timeout=5', '-vconsole:off', 'get', 'Open_vSwitch', '.', 'external_ids:ovn-nb']
root@ovn:/etc/openvswitch#

i have used "apt-get install python-openvswitch" for ovs libs !

Hey,

Looking at the tests/dpdk/ring_client.c. It seems that you are resuing the bpf examples available in examples/bpf like dapper in there. However, I don't see any usage of ubpf_vm in tests/dpdk/ring_client.c. I was expecting the VM to operate in there, right?

At the moment, there is no JITing or interpretation or anything in that file. Is this correct? If yes, would you please point me to some tests that actually run the vm? I'm wondering if that's something we should do at all or not!

Thanks,
Alireza

We need new error messages for the OpenFlow messages introduced in Oko (to load the BPF programs, to attach them to rules, and to update their maps). Without these, the only way to differentiate between the errors is to look at the logs, which the client (e.g., controller) may not have.

Issue and example

While receiving a continuous stream of ICMP packets on port 1,

clang -O2 -target bpf -c examples/bpf/stateless-firewall.c -o /tmp/stateless-firewall.o
ovs-ofctl load-filter-prog br0 1 /tmp/stateless-firewall.o
ovs-ofctl add-flow br0 priority=2,in_port=1,icmp,filter_prog=1,actions=output:2
ovs-ofctl add-flow br0 priority=1,in_port=1,icmp,actions=output:1
ovs-ofctl update-map br0 1 0 key 14 0 16 172 value 1 0 0 0
ovs-ofctl del-flows br0
# ovs-vswitchd should have crashed

The bug isn't triggered without the map update.

Details

Stack trace:

Thread 14 "revalidator32" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fcc7dffb700 (LWP 23533)]
0x000055c92593068b in ovs_list_size (list=0x55c926c168d0) at ./include/openvswitch/list.h:264
264        for (e = list->next; e != list; e = e->next) {
(gdb) bt
#0  0x000055c92593068b in ovs_list_size (list=0x55c926c168d0) at ./include/openvswitch/list.h:264
#1  0x000055c925935447 in revalidate_ukey (udpif=0x55c926c2b800, ukey=0x55c926be7310, stats=0x7fcc7dff8c90, odp_actions=0x7fcc7dff8cb0, reval_seq=74169, recircs=0x7fcc7dff8cf0)
    at ofproto/ofproto-dpif-upcall.c:1924
#2  0x000055c9259366c2 in revalidator_sweep__ (revalidator=0x55c926bd6d10, purge=false) at ofproto/ofproto-dpif-upcall.c:2310
#3  0x000055c9259368ac in revalidator_sweep (revalidator=0x55c926bd6d10) at ofproto/ofproto-dpif-upcall.c:2349
#4  0x000055c92593277d in udpif_revalidator (arg=0x55c926bd6d10) at ofproto/ofproto-dpif-upcall.c:894
#5  0x000055c925a136d6 in ovsthread_wrapper (aux_=0x55c926bf6500) at lib/ovs-thread.c:342
#6  0x00007fcc8efc16db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#7  0x00007fcc8e74488f in clone () from /lib/x86_64-linux-gnu/libc.so.6

According to the stack trace, this is a bug in the revalidation of the cached rules (when deleting flow rules, the whole cache is revalidated).

The reason the map update is needed to trigger this might be that it sets the cache in a specific state. In particular, because of the map update and the continuous stream of packets, we'll have two filter program chains in the cache.