Hi all:
Currently OVS maintains several Statistics counters per interface. "rx_missed_errors" counter is amount them and collects pkts not received due to local resource constaints. Many ovs netdevs support collecting this counter, such as netdev-linux, netdev-dpdk, netdev-bsd and so on. But as far as I know, this counter can't be read by command "ovs-vsctl list interface <int-name>|grep statistics". I have found the root cause(may be I was wrong) is in task "iface_refresh_stats", the "rx_missed_errors" is not in the macro IFACE_STATS. So even if this counter is updated by netdev, it woundn't be read by users.
This simple patch tries to solve this problem, many thanks for your kindly reminder.
Signed-off-by: Liu Chang <liuchang@cmss.chinamobile.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
It's sometimes handy to log an entire Row object, so this just
adds a string representation of the object as:
Tablename(col1=val1, col2=val2, ..., coln=valn)
Signed-off-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
For userspace datapath, currently only the bridge itself, the LOCAL port,
can be the tunnel endpoint to encap/decap tunnel packets. This patch
enables non-bridge port as tunnel endpoint. One use case is for users to
create a bridge and a vtep port as tap, and configure underlay IP at vtep
port as the tunnel endpoint.
This patch causes failure for test "ptap - L3 over patch port". This is
because this test is already using non-bridge port gre1 as tunnel endpoint.
In this test, a flow is added to redirect tunnel packets to gre1 port,
as shown below:
ovs-ofctl add-flow br1 in_port=p1,actions=output=gre1
It later generates a datapath flow which matches an extra eth field:
- recirc_id(0),...,eth_type(0x0800),...
+ recirc_id(0),...,eth(dst=1e:2c:e9:2a:66:9e),eth_type(0x0800),...
With this patch, this flow need only a NORMAL action.
Signed-off-by: William Tu <u9012063@gmail.com>
Co-authored-by: William Tu <u9012063@gmail.com>
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
According to the documentation in the vswtich.xml the maximum
configurable bond-rebalance-interval is 10000ms. However, this is not
enforced anywhere in the code and people are using larger values in
the field.
To avoid confusion this change changes the maximum value the
2147483647 which will fit in 32bit integer. This will allow a value of
~25 days, which should be enough to cover everybody's needs. Note that
a value of 0 disables the automatic rebalancing anyway.
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This may be needed in some special cases, such as to support some hardware
offload implementations. Note that disabling TCP sequence number
verification is not an optimization in itself, but supporting some
hardware offload implementations may offer better performance. TCP
sequence number verification is enabled by default. This option is only
available for the userspace datapath. Access to this option is presently
provided via 'dpctl' commands as the need for this option is quite node
specific, by virtue of which nics are in use on a given node. A test is
added to verify this option.
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-May/359188.html
Signed-off-by: Darrell Ball <dlu998@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The commit [1] removed OVN, but had to leave out some OVN bits
for the ovsdb-server raft testing. But "make install" is installing
ovn-nb/ovn-sb man entries and OVN schema files.
This patch excludes these.
"make install" is also installing ovn-nbctl/ovn-sbctl and this still needs to
be addressed.
[1] - f3e24610ea8("Remove OVN.")
Signed-off-by: Numan Siddique <nusiddiq@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The pid variable is being shadowed by the list comprehension in the
os.execvp() call. This can generate flakes / warnings in some environments
so fix it.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Cache the 'conn' context and use it when it is valid. The cached 'conn'
context will get reset if it is not expected to be valid; the cost to do
this is negligible. Besides being most optimal, this also handles corner
cases, such as decapsulation leading to the same tuple, as in tunnel VPN
cases. A negative test is added to check the resetting of the cached
'conn'.
Signed-off-by: Darrell Ball <dlu998@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The datatype 'pad' in the function 'reverse_nat_packet()' was incorrectly
declared as 'char' instead of 'uint8_t'. This can affect reverse natting
of icmpX packets with padding > 127 bytes. At the same time, add some
comments regarding 'extract_l3_ipvX' usage in this function. Found by
inspection.
Fixes: edd1bef468 ("dpdk: Add more ICMP Related NAT support.")
Signed-off-by: Darrell Ball <dlu998@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Python3 complains if a dict key is changed during the
iteration.
Use list() to create a copy of it.
Traceback (most recent call last):
File "./ovsdb/ovsdb-idlc.in", line 1581, in <module>
func(*args[1:])
File "./ovsdb/ovsdb-idlc.in", line 185, in printCIDLHeader
replace_cplusplus_keyword(schema)
File "./ovsdb/ovsdb-idlc.in", line 179, in replace_cplusplus_keyword
for columnName in table.columns:
RuntimeError: dictionary keys changed during iteration
Signed-off-by: Flavio Leitner <fbl@sysclose.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Valgrind reported that 'pkt->md.ct_orig_tuple.ipv4.ipv4_proto' is
uninitialized in 'check_orig_tuple()', if 'ct_state' is zero. Although
this is true, the check is superceded, as even if it succeeds the check
for natted packets based on 'ct_state' is an ORed condition and is intended
to catch this case.
The check is '!(pkt->md.ct_state & (CS_SRC_NAT | CS_DST_NAT))' which
filters out all packets excepted natted ones. Move this check up to
prevent the Valgrind complaint, which also helps performance and also remove
recenlty added redundant check adding extra cycles.
Fixes: f44733c527 ("conntrack: Validate accessing of conntrack data in pkt_metadata.")
CC: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Darrell Ball <dlu998@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
When parse tnl_push, if IPv4 is used,
we forget to fill the ipv4 version and ip header length fields.
so there is a wrong ip header in the header of "struct ovs_action_push_tnl",
which will caused wrong packdet sent by dpcl.
test command:
ovs-appctl dpctl/add-flow "in_port(1),eth_type(0x0800),ipv4(dst=9.9.9.6)" \
"tnl_push(tnl_port(2),header(size=50,type=4,eth(dst=08:00:27:2e:87:0d,src=98:03:9b:c6:d1:7c,dl_type=0x0800), \
ipv4(src=10.97.240.147,dst=10.96.74.33,proto=17,tos=0,ttl=64,frag=0x4000), \
udp(src=0,dst=4789,csum=0x0),vxlan(flags=0x8000000,vni=0x270f)),out_port(3)),4"
Signed-off-by: Martin Zhang <martinbj2008@gmail.com>
Signed-off-by: Dujie <dujie@didiglobal.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
We don't own ovs.org, and I doubt Ojai Valley School would enjoy
receiving our email.
Reviewed-by: Greg Rose <gvrose8192@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The ofconn packet-in queue for packets that can't be immediately sent
on the rconn connection was limited to 100 packets (hardcoded value).
While increasing this limit is usually not recommended as it might
create buffer bloat and increase latency, in scaled scenarios it is
useful if the administrator (or CMS) can adjust the queue size.
One such situation was noticed while performing scale testing of the
OVN IGMP functionality: triggering ~200 simultaneous IGMP reports
was causing tail drops on the packet-in queue towards ovn-controller.
This commit adds the possibility to configure the queue size for:
- management controller (br-int.mgmt): through the
other_config:controller-queue-size column of the Bridge table. This
value is limited to 512 as large queues definitely affect latency. If
not present the default value of 100 is used. This is done in order to
maintain the same default behavior as before the commit.
- other controllers: through the controller_queue_size column of the
Controller table. This value is also limited to 512. If not present
the code uses the Bridge:other_config:controller-queue-size
configuration.
Acked-by: Mark Michelson <mmichels@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Add support in ovsdb-tool for migrating clustered dbs to standalone dbs.
E.g. usage to migrate nb/sb db to standalone db from raft:
ovsdb-tool cluster-to-standalone ovnnb_db.db ovnnb_db_cluster.db
Acked-by: Han Zhou <hzhou8@ebay.com>
Signed-off-by: Aliasgar Ginwala <aginwala@ebay.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
It's possible that a port added to the system with certain kinds
of invalid parameters will cause the 'could not add' log to be
triggered. When this happens, the vswitch run loop can continually
re-attempt adding the port. While the parameters remain invalid
the vswitch run loop will re-trigger the warning, flooding the
syslog.
This patch adds a simple rate limit to the log.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
While checking valgrind reports after running "make check-valgrind" I have noticed
reports for several tests similar to the following:
....
==5345== Memcheck, a memory error detector
==5345== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5345== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==5345== Command: ovsdb-client --private-key=/home/damijan.skvarc/doma/ovs/tests/testpki-privkey.pem --certificate=/home/damijan.skvarc/doma/ovs/tests/testpki-cert.pem --ca-cert=/home/damijan.skvarc/doma/ovs/tests/testpki-cacert.pem transact ssl:127.0.0.1:40111 \ \ \ ["ordinals",
==5345== \ \ \ \ \ \ {"op":\ "update",
==5345== \ \ \ \ \ \ \ "table":\ "ordinals",
==5345== \ \ \ \ \ \ \ "where":\ [["number",\ "==",\ 1]],
==5345== \ \ \ \ \ \ \ "row":\ {"number":\ 2,\ "name":\ "old\ two"}},
==5345== \ \ \ \ \ \ {"op":\ "update",
==5345== \ \ \ \ \ \ \ "table":\ "ordinals",
==5345== \ \ \ \ \ \ \ "where":\ [["name",\ "==",\ "two"]],
==5345== \ \ \ \ \ \ \ "row":\ {"number":\ 1,\ "name":\ "old\ one"}}]
==5345== Parent PID: 5344
==5345==
==5345==
==5345== HEAP SUMMARY:
==5345== in use at exit: 116,551 bytes in 3,341 blocks
==5345== total heap usage: 5,134 allocs, 1,793 frees, 412,290 bytes allocated
==5345==
==5345== 6,221 (184 direct, 6,037 indirect) bytes in 1 blocks are definitely lost in loss record 498 of 500
==5345== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5345== by 0x5105E77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==5345== by 0x51E1D23: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==5345== by 0x51E4861: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==5345== by 0x51E5414: ASN1_item_ex_d2i (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==5345== by 0x51E546A: ASN1_item_d2i (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==5345== by 0x4E56B27: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==5345== by 0x4E5BA11: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==5345== by 0x4E65145: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==5345== by 0x4522DF: ssl_connect (stream-ssl.c:530)
==5345== by 0x443D38: scs_connecting (stream.c:315)
==5345== by 0x443D38: stream_connect (stream.c:338)
==5345== by 0x443FA1: stream_open_block (stream.c:266)
==5345== by 0x40AB79: open_jsonrpc (ovsdb-client.c:507)
==5345== by 0x40AB79: open_rpc (ovsdb-client.c:143)
==5345== by 0x40B06B: do_transact__ (ovsdb-client.c:871)
==5345== by 0x40B245: do_transact (ovsdb-client.c:893)
==5345== by 0x405F76: main (ovsdb-client.c:282)
==5345==
==5345== LEAK SUMMARY:
==5345== definitely lost: 184 bytes in 1 blocks
==5345== indirectly lost: 6,037 bytes in 117 blocks
==5345== possibly lost: 0 bytes in 0 blocks
==5345== still reachable: 110,330 bytes in 3,223 blocks
==5345== suppressed: 0 bytes in 0 blocks
==5345== Reachable blocks (those to which a pointer was found) are not shown.
==5345== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5345==
==5345== For counts of detected and suppressed errors, rerun with: -v
==5345== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
....
This report was extracted from "index uniqueness checking" test and complains about
leaking memory in ovsdb-client application. The problem is not huge, since ovsdb-client
is CLI tool which is constantly reinvoked/restarted, thus leaked memory is not accumulated.
More problematic issue is that for the same test valgrind reports the similar problem also for
ovsdb-server:
....
==5290== Memcheck, a memory error detector
==5290== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5290== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==5290== Command: ovsdb-server --log-file --detach --no-chdir --pidfile --private-key=/home/damijan.skvarc/doma/ovs/tests/testpki-privkey2.pem --certificate=/home/damijan.skvarc/doma/ovs/tests/testpki-cert2.pem --ca-cert=/home/damijan.skvarc/doma/ovs/tests/testpki-cacert.pem --remote=pssl:0:127.0.0.1 db
==5290== Parent PID: 5289
==5290==
==5292== Warning: noted but unhandled ioctl 0x2403 with no size/direction hints.
==5292== This could cause spurious value errors to appear.
==5292== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==5292== Warning: noted but unhandled ioctl 0x2400 with no size/direction hints.
==5292== This could cause spurious value errors to appear.
==5292== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==5290==
==5290== HEAP SUMMARY:
==5290== in use at exit: 2,066 bytes in 48 blocks
==5290== total heap usage: 87 allocs, 39 frees, 14,152 bytes allocated
==5290==
==5290== LEAK SUMMARY:
==5290== definitely lost: 0 bytes in 0 blocks
==5290== indirectly lost: 0 bytes in 0 blocks
==5290== possibly lost: 0 bytes in 0 blocks
==5290== still reachable: 2,066 bytes in 48 blocks
==5290== suppressed: 0 bytes in 0 blocks
==5290== Reachable blocks (those to which a pointer was found) are not shown.
==5290== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5290==
==5290== For counts of detected and suppressed errors, rerun with: -v
==5290== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)
==5292== Warning: noted but unhandled ioctl 0x2401 with no size/direction hints.
==5292== This could cause spurious value errors to appear.
==5292== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==5292==
==5292== HEAP SUMMARY:
==5292== in use at exit: 164,018 bytes in 4,252 blocks
==5292== total heap usage: 17,910 allocs, 13,658 frees, 1,907,468 bytes allocated
==5292==
==5292== 49,720 (1,472 direct, 48,248 indirect) bytes in 8 blocks are definitely lost in loss record 580 of 580
==5292== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5292== by 0x5105E77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==5292== by 0x51E1D23: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==5292== by 0x51E4861: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==5292== by 0x51E5414: ASN1_item_ex_d2i (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==5292== by 0x51E546A: ASN1_item_d2i (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==5292== by 0x4E53E00: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==5292== by 0x4E55727: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==5292== by 0x452C4B: ssl_connect (stream-ssl.c:530)
==5292== by 0x445B18: scs_connecting (stream.c:315)
==5292== by 0x445B18: stream_connect (stream.c:338)
==5292== by 0x445B91: stream_recv (stream.c:369)
==5292== by 0x432A9C: jsonrpc_recv.part.7 (jsonrpc.c:310)
==5292== by 0x433977: jsonrpc_recv (jsonrpc.c:1139)
==5292== by 0x433977: jsonrpc_session_recv (jsonrpc.c:1112)
==5292== by 0x40CCE3: ovsdb_jsonrpc_session_run (jsonrpc-server.c:553)
==5292== by 0x40CCE3: ovsdb_jsonrpc_session_run_all (jsonrpc-server.c:586)
==5292== by 0x40CCE3: ovsdb_jsonrpc_server_run (jsonrpc-server.c:401)
==5292== by 0x40682E: main_loop (ovsdb-server.c:209)
==5292== by 0x40682E: main (ovsdb-server.c:460)
==5292==
==5292== LEAK SUMMARY:
==5292== definitely lost: 1,472 bytes in 8 blocks
==5292== indirectly lost: 48,248 bytes in 936 blocks
==5292== possibly lost: 0 bytes in 0 blocks
==5292== still reachable: 114,298 bytes in 3,308 blocks
==5292== suppressed: 0 bytes in 0 blocks
==5292== Reachable blocks (those to which a pointer was found) are not shown.
==5292== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5292==
==5292== For counts of detected and suppressed errors, rerun with: -v
==5292== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
....
In this case ovsdb-server is running as daemon process (--detach option) and leaking memory is
accumulated whenever ovsdb-client is reconnected. Within observed test ovsdb-client CLI tool
connects 8 times to ovsdb-server. Leaked memory in ovsdb-client (for each invocation) is approx.
6K bytes, while leaked memory in ovsdb-server is aprox. 48Kbytes what is actually 8*6K. Thus per
each connection both ovsdb-client and ovsdb-server leak approx. 6K bytes.
I have done a small manual test to check if ovsdb-server is indeed accumulating leaked memory
by dumping ovsdb-server in a loop:
console1:
ovsdb-server \
--log-file \
--detach --no-chdir --pidfile \
--private-key=testpki-privkey2.pem \
--certificate=testpki-cert2.pem \
--ca-cert=testpki-cacert.pem \
--remote=pssl:0:127.0.0.1 \
db
while (true); do \
ovsdb-client \
--private-key=testpki-privkey.pem \
--certificate=testpki-cert.pem \
--ca-cert=testpki-cacert.pem \
dump ssl:127.0.0.1:42067; \
done
console2:
watch -n 0.5 'cat /proc/$(pidof ovsdb-server)/status | grep VmSize'
In console2 it was evidently seen ovsdb-server is constantly leaking memory. After a while
(i.e. after a certain number of reconnections) the OOM killer jumps out and kills ovsdb-server.
Very similar situation was already noticed and described in
https://github.com/openvswitch/ovs-issues/issues/168. There, the problem pops up while connecting
controller to ovs-vswitchd daemon.
Valgrind reports point to a problem in openssl library, however after studying openssl code for
a while I have found out the problem is actually in ovs. When connection through SSL channel is
taken place openssl library allocates memory for keeping track of certificate. Reference to this
memory works very similar as std::shared_ptr pointer in recent C++ dialects. i.e. when allocated
memory is referenced its reference counter is incremented and decremented after the memory is
derefered. When reference counter becomes zero allocated memory is automatically deallocated.
In openssl library environment certificate is retrieved by calling SSL_get_peer_certificate()
where its reference counter is incremented. After retrieved certificate is not used any more its
reference counter must be decremented by calling X509_free(). If not, allocated memory is never
freed despite the ssl connection is properly closed.
The problem was caused in stream-ssl.c in function ssl_connect(), which retrieves common peer name
by calling SSL_get_peer_certificate() function and without calling X509_free() function afterwards.
Signed-off-by: Damijan Skvarc <damjan.skvarc@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
I don't actually have any idea whether XenServer has moved
forward to Python 3 these days, but these files are still
OK in Python 2.x as well.
The rest of the Python files in OVS seem to already be OK in
Python 3.
Acked-by: Numan Siddique <nusididq@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
There's nothing in OVS specific to Sphinx for Python 2, but the
compile-time check only looked for a binary named "sphinx-build", which is
typically provided only for Python 2. With Python 3, the binary is
typically called "sphinx-build-3". With this commit, either name is
accepted.
Acked-by: Numan Siddique <nusididq@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
These days Automake uses _build/sub for its distcheck builds, not
plain _build. (I don't know whether that is a change from previous
versions.)
Acked-by: Numan Siddique <nusididq@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Valgrind reported:
1305: ofproto-dpif - conntrack - ipv6
==26942== Conditional jump or move depends on uninitialised value(s)
==26942== at 0x587C00: check_orig_tuple (conntrack.c:1006)
==26942== by 0x587C00: process_one (conntrack.c:1141)
==26942== by 0x587C00: conntrack_execute (conntrack.c:1220)
==26942== by 0x47B00F: dp_execute_cb (dpif-netdev.c:7305)
==26942== by 0x4AF756: odp_execute_actions (odp-execute.c:794)
==26942== by 0x477532: dp_netdev_execute_actions (dpif-netdev.c:7349)
==26942== by 0x477532: handle_packet_upcall (dpif-netdev.c:6630)
==26942== by 0x477532: fast_path_processing (dpif-netdev.c:6726)
==26942== by 0x47933C: dp_netdev_input__ (dpif-netdev.c:6814)
==26942== by 0x479AB8: dp_netdev_input (dpif-netdev.c:6852)
==26942== by 0x479AB8: dp_netdev_process_rxq_port (dpif-netdev.c:4287)
==26942== by 0x47A6A9: dpif_netdev_run (dpif-netdev.c:5264)
==26942== by 0x4324E7: type_run (ofproto-dpif.c:342)
==26942== by 0x41C5FE: ofproto_type_run (ofproto.c:1734)
==26942== by 0x40BAAC: bridge_run__ (bridge.c:2965)
==26942== by 0x410CF3: bridge_run (bridge.c:3029)
==26942== by 0x407614: main (ovs-vswitchd.c:127)
==26942== Uninitialised value was created by a heap allocation
==26942== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26942== by 0x532574: xmalloc (util.c:138)
==26942== by 0x46CD62: dp_packet_new (dp-packet.c:153)
==26942== by 0x4A0431: eth_from_flow_str (netdev-dummy.c:1644)
==26942== by 0x4A0431: netdev_dummy_receive (netdev-dummy.c:1783)
==26942== by 0x531990: process_command (unixctl.c:308)
==26942== by 0x531990: run_connection (unixctl.c:342)
==26942== by 0x531990: unixctl_server_run (unixctl.c:393)
==26942== by 0x40761E: main (ovs-vswitchd.c:128)
1316: ofproto-dpif - conntrack - tcp port reuse
==24039== Conditional jump or move depends on uninitialised value(s)
==24039== at 0x587BF5: check_orig_tuple (conntrack.c:1004)
==24039== by 0x587BF5: process_one (conntrack.c:1141)
==24039== by 0x587BF5: conntrack_execute (conntrack.c:1220)
==24039== by 0x47B02F: dp_execute_cb (dpif-netdev.c:7306)
==24039== by 0x4AF7A6: odp_execute_actions (odp-execute.c:794)
==24039== by 0x47755B: dp_netdev_execute_actions (dpif-netdev.c:7350)
==24039== by 0x47755B: handle_packet_upcall (dpif-netdev.c:6631)
==24039== by 0x47755B: fast_path_processing (dpif-netdev.c:6727)
==24039== by 0x47935C: dp_netdev_input__ (dpif-netdev.c:6815)
==24039== by 0x479AD8: dp_netdev_input (dpif-netdev.c:6853)
==24039== by 0x479AD8: dp_netdev_process_rxq_port
(dpif-netdev.c:4287)
==24039== by 0x47A6C9: dpif_netdev_run (dpif-netdev.c:5264)
==24039== by 0x4324F7: type_run (ofproto-dpif.c:342)
==24039== by 0x41C5FE: ofproto_type_run (ofproto.c:1734)
==24039== by 0x40BAAC: bridge_run__ (bridge.c:2965)
==24039== by 0x410CF3: bridge_run (bridge.c:3029)
==24039== by 0x407614: main (ovs-vswitchd.c:127)
==24039== Uninitialised value was created by a heap allocation
==24039== at 0x4C2DB8F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24039== by 0x5325C4: xmalloc (util.c:138)
==24039== by 0x46D144: dp_packet_new (dp-packet.c:153)
==24039== by 0x46D144: dp_packet_new_with_headroom (dp-packet.c:163)
==24039== by 0x51191E: eth_from_hex (packets.c:498)
==24039== by 0x4A03B9: eth_from_packet (netdev-dummy.c:1609)
==24039== by 0x4A03B9: netdev_dummy_receive (netdev-dummy.c:1765)
==24039== by 0x5319E0: process_command (unixctl.c:308)
==24039== by 0x5319E0: run_connection (unixctl.c:342)
==24039== by 0x5319E0: unixctl_server_run (unixctl.c:393)
==24039== by 0x40761E: main (ovs-vswitchd.c:128)
According to comments in pkt_metadata_init(), conntrack data is valid
only if pkt_metadata.ct_state != 0. This patch prevents
check_orig_tuple() get called when conntrack data is uninitialized.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Valgrind reported:
2491: database commands -- negative checks
==19245== 36 (32 direct, 4 indirect) bytes in 1 blocks are definitely lost in loss record 36 of 53
==19245== at 0x4C2FD5F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19245== by 0x431AB4: xrealloc (util.c:149)
==19245== by 0x41656D: ovsdb_datum_reallocate (ovsdb-data.c:1883)
==19245== by 0x41656D: ovsdb_datum_union (ovsdb-data.c:1961)
==19245== by 0x4107B2: cmd_add (db-ctl-base.c:1494)
==19245== by 0x406E2E: do_vsctl (ovs-vsctl.c:2626)
==19245== by 0x406E2E: main (ovs-vsctl.c:183)
==19252== 16 bytes in 1 blocks are definitely lost in loss record 9 of 52
==19252== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19252== by 0x430F74: xmalloc (util.c:138)
==19252== by 0x414D07: clone_atoms (ovsdb-data.c:990)
==19252== by 0x4153F6: ovsdb_datum_clone (ovsdb-data.c:1012)
==19252== by 0x4104D3: cmd_remove (db-ctl-base.c:1564)
==19252== by 0x406E2E: do_vsctl (ovs-vsctl.c:2626)
==19252== by 0x406E2E: main (ovs-vsctl.c:183)
This patch fixes them.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Valgrind reported:
1122: ofproto-dpif - select group with explicit dp_hash selection method
==16884== 64 bytes in 1 blocks are definitely lost in loss record 320 of 346
==16884== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16884== by 0x532512: xcalloc (util.c:121)
==16884== by 0x4262B9: group_setup_dp_hash_table (ofproto-dpif.c:4846)
==16884== by 0x4267CB: group_set_selection_method (ofproto-dpif.c:4938)
==16884== by 0x4267CB: group_construct (ofproto-dpif.c:4984)
==16884== by 0x417250: init_group (ofproto.c:7286)
==16884== by 0x41B4FC: add_group_start (ofproto.c:7316)
==16884== by 0x42247A: ofproto_group_mod_start (ofproto.c:7589)
==16884== by 0x4250EC: handle_group_mod (ofproto.c:7744)
==16884== by 0x4250EC: handle_single_part_openflow (ofproto.c:8428)
==16884== by 0x4250EC: handle_openflow (ofproto.c:8606)
==16884== by 0x4579E2: ofconn_run (connmgr.c:1318)
==16884== by 0x4579E2: connmgr_run (connmgr.c:355)
==16884== by 0x41E0F5: ofproto_run (ofproto.c:1845)
==16884== by 0x40BA63: bridge_run__ (bridge.c:2971)
==16884== by 0x410CF3: bridge_run (bridge.c:3029)
==16884== by 0x407614: main (ovs-vswitchd.c:127)
This patch fixes it.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Valgrind reported:
1074: ofproto - flush flows, groups, and meters for controller change
==5499== 695 (288 direct, 407 indirect) bytes in 3 blocks are definitely lost in loss record 344 of 355
==5499== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5499== by 0x5E7F145: ??? (in /usr/lib/x86_64-linux-gnu/libunbound.so.2.4.0)
==5499== by 0x5E6EBDE: ub_resolve_async (in /usr/lib/x86_64-linux-gnu/libunbound.so.2.4.0)
==5499== by 0x55C739: resolve_async__.part.5 (dns-resolve.c:233)
==5499== by 0x55C85C: resolve_async__ (dns-resolve.c:261)
==5499== by 0x55C85C: resolve_callback__ (dns-resolve.c:262)
==5499== by 0x5E6FEF1: ub_process (in /usr/lib/x86_64-linux-gnu/libunbound.so.2.4.0)
==5499== by 0x55CAF3: dns_resolve (dns-resolve.c:153)
==5499== by 0x523864: parse_sockaddr_components_dns (socket-util.c:438)
==5499== by 0x523864: parse_sockaddr_components (socket-util.c:504)
==5499== by 0x524468: inet_parse_active (socket-util.c:541)
==5499== by 0x524564: inet_open_active (socket-util.c:579)
==5499== by 0x5959F9: tcp_open (stream-tcp.c:56)
==5499== by 0x529192: stream_open (stream.c:228)
==5499== by 0x529910: stream_open_with_default_port (stream.c:724)
==5499== by 0x595FAE: vconn_stream_open (vconn-stream.c:81)
==5499== by 0x535C9B: vconn_open (vconn.c:250)
==5499== by 0x517C59: reconnect (rconn.c:467)
==5499== by 0x5184C7: run_BACKOFF (rconn.c:492)
==5499== by 0x5184C7: rconn_run (rconn.c:660)
==5499== by 0x457FE8: ofservice_run (connmgr.c:1992)
==5499== by 0x457FE8: connmgr_run (connmgr.c:367)
==5499== by 0x41E0F5: ofproto_run (ofproto.c:1845)
==5499== by 0x40BA63: bridge_run__ (bridge.c:2971)
In ub_resolve_async's callback function, 'struct ub_result' should be
finally freed even if there is a resolving error. This patch fixes it.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Valgrind reported:
1925: schema conversion online - standalone
==10727== 689 (56 direct, 633 indirect) bytes in 1 blocks are definitely lost in loss record 64 of 66
==10727== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10727== by 0x449D42: xcalloc (util.c:121)
==10727== by 0x40F45C: ovsdb_schema_create (ovsdb.c:41)
==10727== by 0x40F7F8: ovsdb_schema_from_json (ovsdb.c:217)
==10727== by 0x40FB4E: ovsdb_schema_from_file (ovsdb.c:101)
==10727== by 0x40B156: do_convert (ovsdb-client.c:1639)
==10727== by 0x4061C6: main (ovsdb-client.c:282)
This patch fixes it.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Valgrind reported:
1925: schema conversion online - standalone
==10884== 689 (56 direct, 633 indirect) bytes in 1 blocks are definitely lost in loss record 384 of 420
==10884== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10884== by 0x44A592: xcalloc (util.c:121)
==10884== by 0x40E2EC: ovsdb_schema_create (ovsdb.c:41)
==10884== by 0x40E688: ovsdb_schema_from_json (ovsdb.c:217)
==10884== by 0x416C6F: ovsdb_trigger_try (trigger.c:246)
==10884== by 0x40D4DE: ovsdb_jsonrpc_trigger_create (jsonrpc-server.c:1119)
==10884== by 0x40D4DE: ovsdb_jsonrpc_session_got_request (jsonrpc-server.c:986)
==10884== by 0x40D4DE: ovsdb_jsonrpc_session_run (jsonrpc-server.c:556)
==10884== by 0x40D4DE: ovsdb_jsonrpc_session_run_all (jsonrpc-server.c:586)
==10884== by 0x40D4DE: ovsdb_jsonrpc_server_run (jsonrpc-server.c:401)
==10884== by 0x406A6E: main_loop (ovsdb-server.c:209)
==10884== by 0x406A6E: main (ovsdb-server.c:460)
'new_schema' should also be freed when there is no error.
This patch fixes it.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Valgrind reported:
1056: ofproto - bundle with multiple flow mods (OpenFlow 1.4)
==19220== 160 bytes in 2 blocks are definitely lost in loss record 24 of 34
==19220== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19220== by 0x4979A4: xmalloc (util.c:138)
==19220== by 0x42407D: miniflow_alloc (flow.c:3340)
==19220== by 0x4296CF: minimatch_init (match.c:1758)
==19220== by 0x46273D: parse_ofp_str__ (ofp-flow.c:1759)
==19220== by 0x465B9E: parse_ofp_str (ofp-flow.c:1790)
==19220== by 0x465CE0: parse_ofp_flow_mod_str (ofp-flow.c:1817)
==19220== by 0x465DF6: parse_ofp_flow_mod_file (ofp-flow.c:1876)
==19220== by 0x410BA3: ofctl_flow_mod_file.isra.19 (ovs-ofctl.c:1773)
==19220== by 0x417933: ovs_cmdl_run_command__ (command-line.c:223)
==19220== by 0x406F68: main (ovs-ofctl.c:179)
This patch fixes it.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Valgrind reported that match.wc was not initialized, as below:
1176: ofproto-dpif - fragment handling - actions
==21214== Conditional jump or move depends on uninitialised value(s)
==21214== at 0x4B77C1: odp_flow_key_from_flow__ (odp-util.c:6143)
==21214== by 0x46DB58: dp_netdev_upcall (dpif-netdev.c:6239)
==21214== by 0x4774A7: handle_packet_upcall (dpif-netdev.c:6608)
==21214== by 0x4774A7: fast_path_processing (dpif-netdev.c:6726)
==21214== by 0x47933C: dp_netdev_input__ (dpif-netdev.c:6814)
==21214== by 0x479AB8: dp_netdev_input (dpif-netdev.c:6852)
==21214== by 0x479AB8: dp_netdev_process_rxq_port (dpif-netdev.c:4287)
==21214== by 0x47A6A9: dpif_netdev_run (dpif-netdev.c:5264)
==21214== by 0x4324E7: type_run (ofproto-dpif.c:342)
==21214== by 0x41C5FE: ofproto_type_run (ofproto.c:1734)
==21214== by 0x40BAAC: bridge_run__ (bridge.c:2965)
==21214== by 0x410CF3: bridge_run (bridge.c:3029)
==21214== by 0x407614: main (ovs-vswitchd.c:127)
==21214== Uninitialised value was created by a stack allocation
==21214== at 0x4769C3: fast_path_processing (dpif-netdev.c:6672)
'match' is allocated on stack but its 'wc' is accessed in
odp_flow_key_from_flow__ without proper initialization.
This patch fixes it.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Valgrind reported:
1210: ofproto-dpif - continuation after clone
==32205== 4,392 (1,440 direct, 2,952 indirect) bytes in 12 blocks are definitely lost in loss record 359 of 362
==32205== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32205== by 0x532574: xmalloc (util.c:138)
==32205== by 0x4F98CA: ofpbuf_init (ofpbuf.c:123)
==32205== by 0x42C07B: nxt_resume (ofproto-dpif.c:5110)
==32205== by 0x41796F: handle_nxt_resume (ofproto.c:3677)
==32205== by 0x424583: handle_single_part_openflow (ofproto.c:8473)
==32205== by 0x424583: handle_openflow (ofproto.c:8606)
==32205== by 0x4579E2: ofconn_run (connmgr.c:1318)
==32205== by 0x4579E2: connmgr_run (connmgr.c:355)
==32205== by 0x41E0F5: ofproto_run (ofproto.c:1845)
==32205== by 0x40BA63: bridge_run__ (bridge.c:2971)
==32205== by 0x410CF3: bridge_run (bridge.c:3029)
==32205== by 0x407614: main (ovs-vswitchd.c:127)
This is because 'xcache' was not destroyed properly. This patch fixes it.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Valgrind reported:
1924: compacting online - cluster
==29312== 2,886 (240 direct, 2,646 indirect) bytes in 6 blocks are definitely lost in loss record 406 of 413
==29312== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29312== by 0x44A5F4: xmalloc (util.c:138)
==29312== by 0x4308EA: json_create (json.c:1451)
==29312== by 0x4308EA: json_object_create (json.c:254)
==29312== by 0x430ED0: json_parser_push_object (json.c:1273)
==29312== by 0x430ED0: json_parser_input (json.c:1371)
==29312== by 0x431CF1: json_lex_input (json.c:991)
==29312== by 0x43233B: json_parser_feed (json.c:1149)
==29312== by 0x41D87F: parse_body.isra.0 (log.c:411)
==29312== by 0x41E141: ovsdb_log_read (log.c:476)
==29312== by 0x42646D: raft_read_log (raft.c:866)
==29312== by 0x42646D: raft_open (raft.c:951)
==29312== by 0x4151AF: ovsdb_storage_open__ (storage.c:81)
==29312== by 0x408FFC: open_db (ovsdb-server.c:642)
==29312== by 0x40657F: main (ovsdb-server.c:358)
This patch fixes it.
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The patch adds 'ip -s -s' to file get_device_stats.out to collect
device statistics. When debugging tunnel related issues, the command
shows much more detailed counters, ex: frame, crc, carrier, helping
to understand the root cause when packets are dropped.
Reviewed-by: Greg Rose <gvrose8192@gmail.com>
Signed-off-by: William Tu <u9012063@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Tables and columns may be abbreviated to unique prefixes, but until
now the error messages have just said there's more than one match.
This commit makes the error messages list the possibilities.
Reviewed-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This will acquire its first user in an upcoming commit.
This function follows the pattern set by svec_join().
Reviewed-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This worked fine as long as there was only one table whose name started
with "C", but now we have three of them.
Acked-by: Justin Pettit <jpettit@ovn.org>
Fixes: 61a5264d60 ("ovs-vswitchd: Add Datapath, CT_Zone, and CT_Zone_Policy tables.")
Signed-off-by: Ben Pfaff <blp@ovn.org>
Redundant line continuation was missed while removing OVN
that broke distdir target and subsequently all the dependent
targets, e.g. distcheck:
make[1]:
*** No rule to make target 'nodist_ovn_lib_libovn_la_SOURCES',
needed by 'distdir'. Stop.
CC: Mark Michelson <mmichels@redhat.com>
Fixes: f3e24610ea ("Remove OVN.")
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Acked-by: Numan Siddique <nusiddiq@redhat.com>
OVN is separated into its own repo. This commit removes the OVN source,
OVN tests, and OVN documentation. It also removes mentions of OVN from
most documentation. The only place where OVN has been left is in
changelogs/NEWS, since we shouldn't mess with the history of the
project.
There is an exception here. The ovsdb-cluster tests rely on ovn-nbctl
and ovn-sbctl to run. Therefore those ovn utilities, as well as their
dependencies remain in the repo with this commit.
Acked-by: Numan Siddique <nusiddiq@redhat.com>
Signed-off-by: Mark Michelson <mmichels@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Useful for tracking where the uninitialized memory came from.
Report example:
Thread 13 revalidator11:
Conditional jump or move depends on uninitialised value(s)
at 0x4C35D96: __memcmp_sse4_1 (in vgpreload_memcheck.so)
by 0x9D4404: ofpbuf_equal (ofpbuf.h:273)
by 0x9D4404: revalidate_ukey__ (ofproto-dpif-upcall.c:2219)
<...>
by 0x6AF488E: clone (clone.S:95)
Uninitialised value was created by a stack allocation
at 0x9D4450: compose_slow_path (ofproto-dpif-upcall.c:1062)
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Tested-by: William Tu <u9012063@gmail.com>
Acked-by: Ben Pfaff <blp@ovn.org>
