Meter commands internally use ofctl_meter_mod__() and
ofctl_meter_request__() functions, which have an optional parameter
called str. When str is NULL, these 2 functions initialize a struct
with meter bands set as NULL. It also needs to set meter n_bands to 0.
Once del-meters change in test dpif-netdev.at is added, the valgrind
report on test '992: dpif-netdev - meters' shows this issue:
Conditional jump or move depends on uninitialised value(s)
at 0x473534: ofputil_put_bands (ofp-meter.c:207)
by 0x473534: ofputil_encode_meter_mod (ofp-meter.c:557)
by 0x40FBA2: ofctl_meter_mod__ (ovs-ofctl.c:4038)
by 0x417BD3: ovs_cmdl_run_command__ (command-line.c:247)
by 0x4078BA: main (ovs-ofctl.c:179)
Uninitialised value was created by a stack allocation
at 0x409350: ofctl_del_meters (ovs-ofctl.c:4088)
Fixes: 3200ed5805 ("ovs-ofctl: Add meter support.")
Signed-off-by: Flavio Fernandes <flavio@flaviof.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The way that "burst_size" was used as total buckets is
very strange. If user set the "burst_size" too smaller while
"rate" larger, that may affect the meter normal work.
This patch refactor the buckets calculation, and start
with a full buckets. It also makes the calculation equal
to what kernel datapath does.
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The Python IDL notification mechanism was sending a notification
for each processed update in a transaction as it was processed.
This causes issues with multi-row changes that contain references
to each other.
For example, if a Logical_Router_Port is created along with a
Gateway_Chassis, and the LRP.gateway_chassis set to that GC, then
when the notify() passes the CREATE event for the LRP, the GC will
not yet have been processed, so __getattr__ when _uuid_to_row fails
to find the GC, will return the default value for LRP.gateway_chassis
which is [].
This patch has the process_update methods return the notifications
that would be produced when a row changes, so they can be queued
and sent after all rows have been processed.
Fixes: d7d417fcddf9 ("Allow subclasses of Idl to define a notification hook")
Signed-off-by: Terry Wilson <twilson@redhat.com>
Acked-by: Brian Haley <haleyb.dev@gmail.com>
Acked-by: Dumitru Ceara <dceara@redhat.com>
Tested-by: Flavio Fernandes <flavio@flaviof.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Userspace datapath relies on fact that every datapath flow has exact
match on the in_port, but flows without in_port match could be
added directly via dpctl commands. Even though dpctl is a debug
interface, datapath should just reject such flows instead of
crashing on assertion.
Fix the following crash and add a unit test for this issue
to tests/dpif-netdev.at:
$ ovs-appctl dpctl/add-flow "eth(),eth_type(0x0800),ipv4()" "3"
unixctl|WARN|error communicating with unix:ovs-vswitchd.ctl: End of file
ovs-appctl: ovs-vswitchd: transaction error (End of file)
ovs-vswitchd.log record:
util(ovs-vswitchd)|EMER|lib/dpif-netdev.c:3638:
assertion match->wc.masks.in_port.odp_port == ODPP_NONE failed
in dp_netdev_flow_add()
daemon_unix(monitor)|ERR|2 crashes: pid 1995 died, killed (Aborted),
core dumped, restarting
Fix result:
$ ovs-appctl dpctl/add-flow "eth(),eth_type(0x0800),ipv4()" "3"
ovs-vswitchd: updating flow table (Invalid argument)
ovs-appctl: ovs-vswitchd: server returned an error
ovs-vswitchd.log record:
dpif_netdev|ERR|failed to put[create] flow: in_port is not an exact match
dpif|WARN|netdev@ovs-netdev: failed to put[create] (Invalid argument)
ufid:7e...d1 eth(src=00..00,dst=00..00),eth_type(0x0800),
ipv4(src=0.0.0.0/0.0.0.0,dst=0.0.0.0/0.0.0.0,proto=0/0,tos=0/0,ttl=0/0), actions:3
Signed-off-by: Mao YingMing <maoyingming@baidu.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When you try to specify `SERVER` to the 'ovsdb-client needs-conversion'
command, it interprets the `SERVER` parameter as the path to the schema
and returns an error.
This PR fixes it.
Fixes: 1b1d2e6daa56 ("ovsdb: Introduce experimental support for clustered databases.")
Submitted-at: https://github.com/openvswitch/ovs/pull/347
Signed-off-by: Alexey Roytman <roytman@il.ibm.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The database is now called "_Server" so look for that instead of
"Open_vSwitch".
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This commit is based on a similar one from OVN by Dumitru Ceara:
a429b24f7bf5 ("ci: Enable AddressSanitizer in Linux clang CI test runs.")
It's useful to run testsuite with address sanitizer enabled to catch
memory leaks and invalid memory accesses. Skipping re-check if
AddressSanitizer reports are present in the test run directory to
not lose them.
Right now OVS has no memory leaks detected on a testsuite run with -O1.
With -O2 there are few false-positive leak reports in test-ovsdb
application, so not using this optimization level for now. For the
same reason not enabling leak detection by default for everyone.
Enabled only in CI.
AddressSanitizer increases execution time for this job from ~12 to ~16
minutes, but it looks like a reasonable sacrifice.
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
While decoding RAW_ENCAP action, decode_ed_prop() might re-allocate
ofpbuf if there is no enough space left. However, function
'decode_NXAST_RAW_ENCAP' continues to use old pointer to 'encap'
structure leading to write-after-free and incorrect decoding.
==3549105==ERROR: AddressSanitizer: heap-use-after-free on address
0x60600000011a at pc 0x0000005f6cc6 bp 0x7ffc3a2d4410 sp 0x7ffc3a2d4408
WRITE of size 2 at 0x60600000011a thread T0
#0 0x5f6cc5 in decode_NXAST_RAW_ENCAP lib/ofp-actions.c:4461:20
#1 0x5f0551 in ofpact_decode ./lib/ofp-actions.inc2:4777:16
#2 0x5ed17c in ofpacts_decode lib/ofp-actions.c:7752:21
#3 0x5eba9a in ofpacts_pull_openflow_actions__ lib/ofp-actions.c:7791:13
#4 0x5eb9fc in ofpacts_pull_openflow_actions lib/ofp-actions.c:7835:12
#5 0x64bb8b in ofputil_decode_packet_out lib/ofp-packet.c:1113:17
#6 0x65b6f4 in ofp_print_packet_out lib/ofp-print.c:148:13
#7 0x659e3f in ofp_to_string__ lib/ofp-print.c:1029:16
#8 0x659b24 in ofp_to_string lib/ofp-print.c:1244:21
#9 0x65a28c in ofp_print lib/ofp-print.c:1288:28
#10 0x540d11 in ofctl_ofp_parse utilities/ovs-ofctl.c:2814:9
#11 0x564228 in ovs_cmdl_run_command__ lib/command-line.c:247:17
#12 0x56408a in ovs_cmdl_run_command lib/command-line.c:278:5
#13 0x5391ae in main utilities/ovs-ofctl.c:179:9
#14 0x7f6911ce9081 in __libc_start_main (/lib64/libc.so.6+0x27081)
#15 0x461fed in _start (utilities/ovs-ofctl+0x461fed)
Fix that by getting a new pointer before using.
Credit to OSS-Fuzz.
Fuzzer regression test will fail only with AddressSanitizer enabled.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27851
Fixes: f839892a206a ("OF support and translation of generic encap and decap")
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Although not required, padding can be optionally added until
the packet length is MTU bytes. A packet with extra padding
currently fails sanity checks.
Vulnerability: CVE-2020-35498
Fixes: fa8d9001a624 ("miniflow_extract: Properly handle small IP packets.")
Reported-by: Joakim Hindersson <joakim.hindersson@elastx.se>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Flavio Leitner <fbl@sysclose.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
I would have found these useful for the OVN tests. The {in} operator
is the same as {<=}, but it's still useful to have the alternate syntax
because most of the time we think of set inclusion separately from
set subsets. The {not-in} operator is different from any existing
operator though.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
Testpmd has been renamed to dpdk-testpmd as of DPDK 20.11.
This commit resolves this issue and fixes these tests.
Signed-off-by: Emma Finn <emma.finn@intel.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The same icmp packet may traverse conntrack module more than once.
Or same icmp packets traverse contranck module in orderly.
Don't change state to CS_ESTABLISHED before receiving reply or related packets.
Fixes: a867c010ee91 ("conntrack: Fix conntrack new state")
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Yi-Hung Wei <yihung.wei@gmail.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Until now, "test-ovsdb idl" has printed the steps that it goes through
to stdout. This commit also makes it log the same information. This
makes it easier to match up the steps with the rest of the log (in
particular with the jsonrpc logging).
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
Currently, ovsdb-server stores complete value for the column in a database
file and in a raft log in case this column changed. This means that
transaction that adds, for example, one new acl to a port group creates
a log entry with all UUIDs of all existing acls + one new. Same for
ports in logical switches and routers and more other columns with sets
in Northbound DB.
There could be thousands of acls in one port group or thousands of ports
in a single logical switch. And the typical use case is to add one new
if we're starting a new service/VM/container or adding one new node in a
kubernetes or OpenStack cluster. This generates huge amount of traffic
within ovsdb raft cluster, grows overall memory consumption and hurts
performance since all these UUIDs are parsed and formatted to/from json
several times and stored on disks. And more values we have in a set -
more space a single log entry will occupy and more time it will take to
process by ovsdb-server cluster members.
Simple test:
1. Start OVN sandbox with clustered DBs:
# make sandbox SANDBOXFLAGS='--nbdb-model=clustered --sbdb-model=clustered'
2. Run a script that creates one port group and adds 4000 acls into it:
# cat ../memory-test.sh
pg_name=my_port_group
export OVN_NB_DAEMON=$(ovn-nbctl --pidfile --detach --log-file -vsocket_util:off)
ovn-nbctl pg-add $pg_name
for i in $(seq 1 4000); do
echo "Iteration: $i"
ovn-nbctl --log acl-add $pg_name from-lport $i udp drop
done
ovn-nbctl acl-del $pg_name
ovn-nbctl pg-del $pg_name
ovs-appctl -t $(pwd)/sandbox/nb1 memory/show
ovn-appctl -t ovn-nbctl exit
---
4. Check the current memory consumption of ovsdb-server processes and
space occupied by database files:
# ls sandbox/[ns]b*.db -alh
# ps -eo vsz,rss,comm,cmd | egrep '=[ns]b[123].pid'
Test results with current ovsdb log format:
On-disk Nb DB size : ~369 MB
RSS of Nb ovsdb-servers: ~2.7 GB
Time to finish the test: ~2m
In order to mitigate memory consumption issues and reduce computational
load on ovsdb-servers let's store diff between old and new values
instead. This will make size of each log entry that adds single acl to
port group (or port to logical switch or anything else like that) very
small and independent from the number of already existing acls (ports,
etc.).
Added a new marker '_is_diff' into a file transaction to specify that
this transaction contains diffs instead of replacements for the existing
data.
One side effect is that this change will actually increase the size of
file transaction that removes more than a half of entries from the set,
because diff will be larger than the resulted new value. However, such
operations are rare.
Test results with change applied:
On-disk Nb DB size : ~2.7 MB ---> reduced by 99%
RSS of Nb ovsdb-servers: ~580 MB ---> reduced by 78%
Time to finish the test: ~1m27s ---> reduced by 27%
After this change new ovsdb-server is still able to read old databases,
but old ovsdb-server will not be able to read new ones.
Since new servers could join ovsdb cluster dynamically it's hard to
implement any runtime mechanism to handle cases where different
versions of ovsdb-server joins the cluster. However we still need to
handle cluster upgrades. For this case added special command line
argument to disable new functionality. Documentation updated with the
recommended way to upgrade the ovsdb cluster.
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This follows up on commit 4241d652e465 ("jsonrpc: Avoid disconnecting
prematurely due to long poll intervals."), which implemented the same
thing in C.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Requested-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
When you would like to add, modify, or delete a lot of flows in the
datapath, for example when you want to measure performance, adding
one flow at the time won't scale. This as it takes a decent amount
of time to set up the datapath connection.
This new command is in-line with the same command available in
ovs-ofctl which allows the same thing, with the only difference that
we do not verify all lines before we start execution. This allows for
a continuous add/delete stream. For example with a command like this:
python3 -c 'while True:
for i in range(0, 1000):
print("add in_port(0),eth(),eth_type(0x800),ipv4(src=100.1.{}.{}) 1".format(int(i / 256), i % 256))
for i in range(0, 1000):
print("delete in_port(0),eth(),eth_type(0x800),ipv4(src=100.1.{}.{})".format(int(i / 256), i % 256))' \
| sudo utilities/ovs-dpctl add-flows -
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
There are various L3 encapsulation standards using UDP being discussed to
leverage the UDP based load balancing capability of different networks.
MPLSoUDP (__ https://tools.ietf.org/html/rfc7510) is one among them.
The Bareudp tunnel provides a generic L3 encapsulation support for
tunnelling different L3 protocols like MPLS, IP, NSH etc. inside a UDP
tunnel.
An example to create bareudp device to tunnel MPLS traffic is
given
$ ovs-vsctl add-port br_mpls udp_port -- set interface udp_port \
type=bareudp options:remote_ip=2.1.1.3
options:local_ip=2.1.1.2 \
options:payload_type=0x8847 options:dst_port=6635
The bareudp device supports special handling for MPLS & IP as
they can have multiple ethertypes. MPLS procotcol can have ethertypes
ETH_P_MPLS_UC (unicast) & ETH_P_MPLS_MC (multicast). IP protocol can have
ethertypes ETH_P_IP (v4) & ETH_P_IPV6 (v6).
The bareudp device to tunnel L3 traffic with multiple ethertypes
(MPLS & IP) can be created by passing the L3 protocol name as string in
the field payload_type. An example to create bareudp device to tunnel
MPLS unicast & multicast traffic is given below.::
$ ovs-vsctl add-port br_mpls udp_port -- set interface
udp_port \
type=bareudp options:remote_ip=2.1.1.3
options:local_ip=2.1.1.2 \
options:payload_type=mpls options:dst_port=6635
Signed-off-by: Martin Varghese <martin.varghese@nokia.com>
Acked-By: Greg Rose <gvrose8192@gmail.com>
Tested-by: Greg Rose <gvrose8192@gmail.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Too big userdata could overflow netlink message leading to out-of-bound
memory accesses or assertion while formatting nested actions.
Fix that by checking the size and returning correct error code.
Credit to OSS-Fuzz.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27640
Fixes: e995e3df57ea ("Allow OVS_USERSPACE_ATTR_USERDATA to be variable length.")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Flavio Leitner <fbl@sysclose.org>
The n_offloaded_flows counter is saved in dpif, and this is the first
one when ofproto is created. When flow operation is done by ovs-appctl
commands, such as, dpctl/add-flow, a new dpif is opened, and the
n_offloaded_flows in it can't be used. So, instead of using counter,
the number of offloaded flows is queried from each netdev, then sum
them up. To achieve this, a new API is added in netdev_flow_api to get
how many flows assigned to a netdev.
In order to get better performance, this number is calculated directly
from tc_to_ufid hmap for netdev-offload-tc, because flow dumping by tc
takes much time if there are many flows offloaded.
Fixes: af0618470507 ("dpif-netlink: Count the number of offloaded rules")
Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
AddressSanitizer reports this as a leak.
Let's just free the memory before exiting to avoid the noise.
'stream_close()' doesn't update the pointer, so this will not
change the return value.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Paolo Valerio <pvalerio@redhat.com>
Currently, userspace conntrack only tracks TCP, UDP, and ICMP, and all
other IP protocols are discarded, and the +inv state is returned. This
is not in line with the kernel conntrack. Where if no L4 information can
be extracted it's treated as generic L3. The change below mimics the
behavior of the kernel.
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Open vSwitch has a few different jsonrpc-based protocols that depend on
jsonrpc_session to make sure that the connection is up and working.
In turn, jsonrpc_session uses the "reconnect" state machine to send
probes if nothing is received. This works fine in normal circumstances.
In unusual circumstances, though, it can happen that the program is
busy and doesn't even try to receive anything for a long time. Then the
timer can time out without a good reason; if it had tried to receive
something, it would have.
There's a solution that the clients of jsonrpc_session could adopt.
Instead of first calling jsonrpc_session_run(), which is what calls into
"reconnect" to deal with timing out, and then calling into
jsonrpc_session_recv(), which is what tries to receive something, they
could use the opposite order. That would make sure that the timeout
was always based on a recent attempt to receive something. Great.
The actual code in OVS that uses jsonrpc_session, though, tends to use
the opposite order, and there are enough users and this is a subtle
enough issue that it could get flipped back around even if we fixed it
now. So this commit takes a different approach. Instead of fixing
this in the users of jsonrpc_session, we fix it in the users of
reconnect: make them tell when they've tried to receive something (or
disable this particular feature).
This commit fixes the problem that way. It's kind of hard to reproduce
but I'm pretty sure that I've seen it a number of times in testing.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
For some reason, while running cluster torture tests in GitHub Actions
workflow, failure of 'echo' command doesn't fail the loop and subshell
never exits, but keeps infinitely printing errors after breaking from
the loop on the right side of the pipeline:
testsuite: line 8591: echo: write error: Broken pipe
Presumably, that is caused by some shell configuration option, but
I have no idea which one and I'm not able to reproduce locally with
shell configuration options provided in GitHub documentation.
Let's just add an explicit 'exit' on 'echo' failure. This will
guarantee exit from the loop and the subshell regardless of
configuration.
Fixes: 0f03ae3754ec ("ovsdb: Improve timing in cluster torture test.")
Acked-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Considering the following updates processed by an IDL client:
1. Delete row R1 from table A while R1 is also referenced by row R2 from
table B:
- because row R2 still refers to row R1, this will create an orphan
R1 but also sets row->tracked_old_datum to report to the IDL client
that the row has been deleted.
2. Insert row R1 to table A.
- because orphan R1 already existed in the IDL, it will be reused.
- R1 still has row->tracked_old_datum set (and may also be on the
table->track_list).
3. Delete row R2 from table B and row R1 from table A.
- row->tracked_old_datum is set again but the previous
tracked_old_datum was never freed.
IDL clients use the deleted old_datum values so when multiple delete
operations are received for a row, always track the first one as that
will match the contents of the row the IDL client knew about.
Running the newly added test case with valgrind, without the fix,
produces the following report:
==23113== 327 (240 direct, 87 indirect) bytes in 1 blocks are definitely lost in loss record 43 of 43
==23113== at 0x4C29F73: malloc (vg_replace_malloc.c:309)
==23113== by 0x476761: xmalloc (util.c:138)
==23113== by 0x45D8B3: ovsdb_idl_insert_row (ovsdb-idl.c:3431)
==23113== by 0x45B7F9: ovsdb_idl_process_update2 (ovsdb-idl.c:2670)
==23113== by 0x45AFCF: ovsdb_idl_db_parse_update__ (ovsdb-idl.c:2479)
==23113== by 0x45B262: ovsdb_idl_db_parse_update (ovsdb-idl.c:2542)
==23113== by 0x45ABBE: ovsdb_idl_db_parse_update_rpc (ovsdb-idl.c:2358)
==23113== by 0x4576DD: ovsdb_idl_process_msg (ovsdb-idl.c:865)
==23113== by 0x457973: ovsdb_idl_run (ovsdb-idl.c:944)
==23113== by 0x40B7B9: do_idl (test-ovsdb.c:2523)
==23113== by 0x44425D: ovs_cmdl_run_command__ (command-line.c:247)
==23113== by 0x44430E: ovs_cmdl_run_command (command-line.c:278)
==23113== by 0x404BA6: main (test-ovsdb.c:76)
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When idl removes orphan rows, those rows are inserted into the
'track_list'. This allows iterators such as *_FOR_EACH_TRACKED () to
return orphan rows that never had any data to the IDL user. In this
case, it is difficult for the user to understand whether it is a row
with no data (there was no "insert" / "modify" for this row) or it is
a row with zero data (columns were cleared by DB transaction).
The main problem with this condition is that rows without data will
have NULL pointers instead of references that should be there according
to the database schema. For example, ovn-controller might crash:
ERROR: AddressSanitizer: SEGV on unknown address 0x000000000100
(pc 0x00000055e9b2 bp 0x7ffef6180880 sp 0x7ffef6180860 T0)
The signal is caused by a READ memory access.
Hint: address points to the zero page.
#0 0x55e9b1 in handle_deleted_lport /controller/binding.c
#1 0x55e903 in handle_deleted_vif_lport /controller/binding.c:2072:5
#2 0x55e059 in binding_handle_port_binding_changes /controller/binding.c:2155:23
#3 0x5a6395 in runtime_data_sb_port_binding_handler /controller/ovn-controller.c:1454:10
#4 0x5e15b3 in engine_compute /lib/inc-proc-eng.c:306:18
#5 0x5e0faf in engine_run_node /lib/inc-proc-eng.c:352:14
#6 0x5e0e04 in engine_run /lib/inc-proc-eng.c:377:9
#7 0x5a03de in main /controller/ovn-controller.c
#8 0x7f4fd9c991a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
#9 0x483f0d in _start (/controller/ovn-controller+0x483f0d)
It doesn't make much sense to return non-real rows to the user, so it's
best to exclude them from iteration.
Test included. Without the fix, provided test will print empty orphan
rows that was never received by idl as tracked changes.
Fixes: 932104f483ef ("ovsdb-idl: Add support for change tracking.")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Dumitru Ceara <dceara@redhat.com>
This is a unit test for the overflow detection issue fixed by commit
a1d2c5f5d9ed ("sha1: Fix algorithm for data bigger than 512 megabytes.")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Paolo Valerio <pvalerio@redhat.com>
Tested-by: Paolo Valerio <pvalerio@redhat.com>
Coding style says: "Put a space between the ``()`` used in a cast and
the expression whose type is cast: ``(void *) 0``.".
This style rule is frequently overlooked. Let's check for it.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Ian Stokes <ian.stokes@intel.com>
If an IDL client sets the same monitor condition twice, the expected
seqno when the IDL contents are updated should be the same for both
calls.
In the following scenario:
1. Client calls ovsdb_idl_db_set_condition(db, table, cond1)
2. ovsdb_idl sends monitor_cond_change(cond1) but the server doesn't yet
reply.
3. Client calls ovsdb_idl_db_set_condition(db, table, cond1)
At step 3 the returned expected seqno should be the same as at step 1.
Similarly, if step 2 is skipped, i.e., the client calls sets
the condition twice in the same iteration, then both
ovsdb_idl_db_set_condition() calls should return the same value.
Fixes: 46437c5232bd ("ovsdb-idl: Enhance conditional monitoring API")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Currently all functions of the type *_is_new() always return
'false'. This patch resolves this issue by using the
'OVSDB_IDL_CHANGE_INSERT' 'change_seqno' instead of the
'OVSDB_IDL_CHANGE_MODIFY' 'change_seqno' to determine if a row
is new and by resetting the 'OVSDB_IDL_CHANGE_INSERT'
'change_seqno' on clear.
Further to this, the code is also updated to match the following
behaviour:
When a row is inserted, the 'OVSDB_IDL_CHANGE_INSERT'
'change_seqno' is updated to match the new database
change_seqno. The 'OVSDB_IDL_CHANGE_MODIFY' 'change_seqno'
is not set for inserted rows (only for updated rows).
At the end of a run, ovsdb_idl_db_track_clear() should be
called to clear all tracking information, this includes
resetting all row 'change_seqno' to zero. This will ensure
that subsequent runs will not see a previously 'new' row.
add_tracked_change_for_references() is updated to only
track rows that reference the current row.
Also, update unit tests in order to test the *_is_new(),
*_is_delete() functions.
Suggested-by: Dumitru Ceara <dceara@redhat.com>
Reported-at: https://bugzilla.redhat.com/1883562
Fixes: ca545a787ac0 ("ovsdb-idl.c: Increase seqno for change-tracking of table references.")
Signed-off-by: Mark Gray <mark.d.gray@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Invocations of CHECK_STREAM_OPEN_BLOCK_PY was accidentally removed
during python2 to python3 conversion. So, these tests was not
checked since that time.
This change returns tests back. CHECK_STREAM_OPEN_BLOCK_PY needed
updates, so instead I refactored function for C tests to be able to
perform python tests too. Also, added test for python with IPv6.
Fixes: 1ca0323e7c29 ("Require Python 3 and remove support for Python 2.")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Gaetan Rivet <grive@u256.net>
Currently "ovs-ofctl parse-flows (NXM)" test doesn't test MPLS fields at all.
This commit adds a test for the the 4 MPLS fields (mpls_label, mpls_tc,
mpls_bos and mpls_ttl) to "ovs-ofctl parse-flows (NXM)" test.
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Length of nested attributes must be checked before storing to the
header. If current length exceeds the maximum value parsing should
fail, otherwise the length value will be truncated leading to
corrupted netlink message and out-of-bound memory accesses:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6310002cc838
at pc 0x000000575470 bp 0x7ffc6c322d60 sp 0x7ffc6c322d58
READ of size 1 at 0x6310002cc838 thread T0
SCARINESS: 12 (1-byte-read-heap-buffer-overflow)
#0 0x57546f in format_generic_odp_key lib/odp-util.c:2738:39
#1 0x559e70 in check_attr_len lib/odp-util.c:3572:13
#2 0x56581a in format_odp_key_attr lib/odp-util.c:4392:9
#3 0x5563b9 in format_odp_action lib/odp-util.c:1192:9
#4 0x555d75 in format_odp_actions lib/odp-util.c:1279:13
...
Fix that by checking the length of nested netlink attributes before
updating 'nla_len' inside the header. Additionally introduced
assertion inside nl_msg_end_nested() to catch this kind of issues
before actual overflow happened.
Credit to OSS-Fuzz.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20003
Fixes: 65da723b40a5 ("odp-util: Format tunnel attributes directly from netlink.")
Acked-by: Flavio Leitner <fbl@sysclose.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
"ovs-appctl dpctl/dump-flows" added the option
"pmd" which allow user to dump pmd specified.
That option is useful to dump rules of pmd
when we have a large number of rules in dp.
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Gaetan Rivet <grive@u256.net>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The new term is "member".
Most of these changes should not change user-visible behavior. One
place where they do is in "ovs-ofctl dump-flows", which will now output
"members:..." inside "bundle" actions instead of "slaves:...". I don't
expect this to cause real problems in most systems. The old syntax
is still supported on input for backward compatibility.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
OVS uses memcmp to compare actions of existing and new flows, but
'struct ofp_ed_prop_nsh_md_type' and corresponding ofpact structure has
3 bytes of padding that never initialized and passed around within OF
data structures and messages.
Uninitialized bytes in MemcmpInterceptorCommon
at offset 21 inside [0x7090000003f8, 136)
WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x4a184e in bcmp (vswitchd/ovs-vswitchd+0x4a184e)
#1 0x896c8a in ofpacts_equal lib/ofp-actions.c:9121:31
#2 0x564403 in replace_rule_finish ofproto/ofproto.c:5650:37
#3 0x563462 in add_flow_finish ofproto/ofproto.c:5218:13
#4 0x54a1ff in ofproto_flow_mod_finish ofproto/ofproto.c:8091:17
#5 0x5433b2 in handle_flow_mod__ ofproto/ofproto.c:6216:17
#6 0x56a2fc in handle_flow_mod ofproto/ofproto.c:6190:17
#7 0x565bda in handle_single_part_openflow ofproto/ofproto.c:8504:16
#8 0x540b25 in handle_openflow ofproto/ofproto.c:8685:21
#9 0x6697fd in ofconn_run ofproto/connmgr.c:1329:13
#10 0x668e6e in connmgr_run ofproto/connmgr.c:356:9
#11 0x53f1bc in ofproto_run ofproto/ofproto.c:1890:5
#12 0x4ead0c in bridge_run__ vswitchd/bridge.c:3250:9
#13 0x4e9bc8 in bridge_run vswitchd/bridge.c:3309:5
#14 0x51c072 in main vswitchd/ovs-vswitchd.c:127:9
#15 0x7f23a99011a2 in __libc_start_main (/lib64/libc.so.6)
#16 0x46b92d in _start (vswitchd/ovs-vswitchd+0x46b92d)
Uninitialized value was stored to memory at
#0 0x4745aa in __msan_memcpy.part.0 (vswitchd/ovs-vswitchd)
#1 0x54529f in rule_actions_create ofproto/ofproto.c:3134:5
#2 0x54915e in ofproto_rule_create ofproto/ofproto.c:5284:11
#3 0x55d419 in add_flow_init ofproto/ofproto.c:5123:17
#4 0x54841f in ofproto_flow_mod_init ofproto/ofproto.c:7987:17
#5 0x543250 in handle_flow_mod__ ofproto/ofproto.c:6206:13
#6 0x56a2fc in handle_flow_mod ofproto/ofproto.c:6190:17
#7 0x565bda in handle_single_part_openflow ofproto/ofproto.c:8504:16
#8 0x540b25 in handle_openflow ofproto/ofproto.c:8685:21
#9 0x6697fd in ofconn_run ofproto/connmgr.c:1329:13
#10 0x668e6e in connmgr_run ofproto/connmgr.c:356:9
#11 0x53f1bc in ofproto_run ofproto/ofproto.c:1890:5
#12 0x4ead0c in bridge_run__ vswitchd/bridge.c:3250:9
#13 0x4e9bc8 in bridge_run vswitchd/bridge.c:3309:5
#14 0x51c072 in main vswitchd/ovs-vswitchd.c:127:9
#15 0x7f23a99011a2 in __libc_start_main (/lib64/libc.so.6)
Uninitialized value was created by an allocation of 'ofpacts_stub'
in the stack frame of function 'handle_flow_mod'
#0 0x569e80 in handle_flow_mod ofproto/ofproto.c:6170
This could cause issues with flow modifications or other operations.
To reproduce, some NSH tests could be run under valgrind or clang
MemorySantizer. Ex. "nsh - md1 encap over a veth link" test.
Fix that by clearing padding bytes while encoding and decoding.
OVS will still accept OF messages with non-zero padding from
controllers.
New tests added to tests/ofp-actions.at.
Fixes: 1fc11c5948cf ("Generic encap and decap support for NSH")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Jan Scheurich <jan.scheurich@ericsson.com>
There is one remaining use under datapath. That change should happen
upstream in Linux first according to our usual policy.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
When running OVSDB cluster tests on Windows not all the ovsdb processes
are terminated. Queue up the pids of the started processes for
termination when the test stops.
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
ovs-router module checks for the source ip address of the interface
while adding a new route. netdev module doesn't request ip addresses
from the system every time, but instead it caches currently assigned
ip addresses and updates the cache on netlink notifications if needed.
So, there is a slight delay between setting ip address on interface
in a system and a moment OVS updates list of ip addresses of this
interface. If route addition happens within this time frame, it
fails with the following error:
# ovs-appctl ovs/route/add 10.0.0.0/24 br-p1
Error while inserting route.
ovs-appctl: ovs-vswitchd: server returned an error
This makes system tests to fail frequently.
Let's wait until local route successfully added. This will mean
that OVS finished processing of a netlink event and will use up to
date list of ip addresses on desired interface.
Fixes: 526cf4e1d6a8 ("tests: Added unit tests in packet-type-aware.at")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Aaron Conole <aconole@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
When running OVSDB cluster tests on Windows not all the ovsdb
processes are terminated.
Strip carriage return and newline of the arguments passed to the kill
command because they will cause problems when passing them to tasklist
and taskkill.
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
The test 'Check Python IDL reconnects to leader - Python3
(leader only)' fails sometimes when the first ovsdb-server
gets killed before the others had joined the cluster.
Fix the function ovsdb_cluster_start_idltest to wait them
to join the cluster.
Fixes: c39751e44539 ("python: Monitor Database table to manage lifecycle of IDL client.")
Co-authored-by:: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Flavio Leitner <fbl@sysclose.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Builds on RHEL 8.2 systems are failing due to this issue.
See [1] as to why this is necessary.
I used the following command to identify files that need this fix:
find . -type f -executable | /usr/lib/rpm/redhat/brp-mangle-shebangs
I also updated the copyright notices as needed.
1. https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error
Fixes: 1ca0323e7c29 ("Require Python 3 and remove support for Python 2.")
Signed-off-by: Greg Rose <gvrose8192@gmail.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Packets in the benchmark must be treated as new packets, i.e. they
should not have conntrack metadata set. Current code will set up
'pkt->md.conn' after the first run and all subsequent calls will hit
the 'fast' processing that is intended for recirculated packets making
a false impression that current conntrack implementation is lightning
fast.
Before the change:
$ ./ovstest test-conntrack benchmark 4 33554432 32 1
conntrack: 1059 ms
After (correct):
$ ./ovstest test-conntrack benchmark 4 33554432 32 1
conntrack: 92785 ms
Fixes: 594570ea1cde ("conntrack: Optimize recirculations.")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Aaron Conole <aconole@redhat.com>
When commit a0baa7dfa4fe ("connmgr: Make treatment of active and passive
connections more uniform") was applied, it did not take into account
that a reconfiguration of the allowed_versions setting would require a
reload of the ofservice object (only accomplished via a restart of OvS).
For now, during the reconfigure cycle, we delete the ofservice object and
then recreate it immediately. A new test is added to ensure we do not
break this behavior again.
Fixes: a0baa7dfa4fe ("connmgr: Make treatment of active and passive connections more uniform")
Suggested-by: Ben Pfaff <blp@ovn.org>
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1782834
Signed-off-by: Aaron Conole <aconole@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Numan Siddique <numans@ovn.org>
Tested-by: Numan Siddique <numans@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Every time a follower has to install a snapshot received from the
leader, it should also replace the data in memory. Right now this only
happens when snapshots are installed that also change the schema.
This can lead to inconsistent DB data on follower nodes and the snapshot
may fail to get applied.
Fixes: bda1f6b60588 ("ovsdb-server: Don't disconnect clients after raft install_snapshot.")
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
While committing set() actions, commit() could wildcard all the fields
that are same in match key and in the set action. This leads to
situation where mask after commit could actually contain less bits
than it was before. And if set action was partially committed, all
the fields that were the same will be cleared out from the matching key
resulting in the incorrect (too wide) flow.
For example, for the flow that matches on both src and dst mac
addresses, if the dst mac is the same and only src should be changed
by the set() action, destination address will be wildcarded in the
match key and will never be matched, i.e. flows with any destination
mac will match, which is not correct.
Setting OF rule:
in_port=1,dl_src=50:54:00:00:00:09 actions=mod_dl_dst(50:54:00:00:00:0a),output(2)
Sending following packets on port 1:
1. eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800)
2. eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0c),eth_type(0x0800)
3. eth(src=50:54:00:00:00:0b,dst=50:54:00:00:00:0c),eth_type(0x0800)
Resulted datapath flows:
eth(dst=50:54:00:00:00:0c),<...>, actions:set(eth(dst=50:54:00:00:00:0a)),2
eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),<...>, actions:2
The first flow doesn't have any match on source MAC address and the
third packet successfully matched on it while it must be dropped.
Fix that by updating the match mask with only the new bits set by
commit(), but keeping those that were cleared (OR operation).
With fix applied, resulted correct flows are:
eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),<...>, actions:2
eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0c),<...>,
actions:set(eth(dst=50:54:00:00:00:0a)),2
eth(src=50:54:00:00:00:0b),<...>, actions:drop
The code before commit dbf4a92800d0 was not able to reduce the mask,
it was only possible to expand it to exact match, so it was OK to
update original matching mask with the new value in all cases.
Fixes: dbf4a92800d0 ("odp-util: Do not rewrite fields with the same values as matched")
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1854376
Acked-by: Eli Britstein <elibr@mellanox.com>
Tested-by: Adrián Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Current OVS intercepts and processes all BFD packets, thus VM-2-VM
BFD packets get lost and the recipient VM never sees them.
This patch fixes it by only intercepting and processing BFD packets
destined to a configured BFD instance, and other BFD packets are made
available to the OVS flow table for forwarding.
This patch keeps BFD's backward compatibility.
VMware-BZ: #2579326
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: William Tu <u9012063@gmail.com>
Certain Linux distributions, like CentOS, have default iptable
rules to reject input traffic from br-underlay. Refactor by
creating a macro 'IPTABLES_ACCEPT([bridge])' for adding the
accept rule to the iptable input chain.
Signed-off-by: William Tu <u9012063@gmail.com>
