When the compilation dependency is groff-1.23, the following message is
displayed in the compilation log, and the compilation fails:
troff:vswitchd/ovs-vswitchd.8:1298: warning: cannot select font 'CW'
make[1]: *** [Makefile:6761: manpage-check] Error 1
CW font was removed and and now groff warns about non-existent font:
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=d75ea8b2e283e37bd560e821fa4597065f36725f)
Fix that by replacing CW with CR. CW supposed to be an alias of CR
anyway.
Submitted-at: https://github.com/openvswitch/ovs/pull/416
Co-authored-by: Xiaojie Chen <jackchanx@163.com>
Signed-off-by: Xiaojie Chen <jackchanx@163.com>
Signed-off-by: gordonwwang <gordonwwang@tencent.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Add an additional coverage counter for the case where no controller is
available to receive a OFPT_PACKET_IN/NXT_PACKET_IN2 message and so the
message is not sent at all.
This should help investigate issues where controller actions are not
properly executed (for example an OVN reject ACL was supposed to be
executed but ovn-controller was not started and the client ended up
timing out).
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: François Rigault <frigo@amadeus.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
push_dp_ops only handles delete ops errors but ignores the modify
ops results. It's better to handle all the dp operation errors in
a consistent way.
This patch prevents the inconsistency by considering modify failure
in revalidators.
To note, we cannot perform two state transitions and change ukey_state
into UKEY_EVICTED directly here, because, if we do so, the
sweep will remove the ukey alone and leave dp flow alive. Later, the
dump will retrieve the dp flow and might even recover it. This will
contribute the stats of this dp flow twice.
Signed-off-by: Peng He <hepeng.0320@bytedance.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
It's fairly common to have veth0/veth1 interfaces on a system,
but that breaks SRv6 tests that are trying to create them.
Adding ovs- prefix to avoid name collision.
Fixes: 03fc1ad78521 ("userspace: Add SRv6 tunnel support.")
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
OVS allows overlapping megaflows, as long as the actions of these
megaflows are equal. However, the current implementation of action
modification relies on flow_lookup instead of UFID, this could result
in looking up a wrong megaflow and make the ukeys and megaflows
inconsistent.
Just like the test case in the patch, at first we have a rule with the
prefix:
10.1.2.0/24
And we will get a megaflow with prefixes 10.1.2.2/24 when a packet with
IP 10.1.2.2 is received.
Then suppose we change the rule into 10.1.0.0/16. OVS prefers to keep
the 10.1.2.2/24 megaflow and just changes its action instead of
extending the prefix into 10.1.2.2/16.
Then suppose we have a 10.1.0.2 packet, since it misses the megaflow,
this time, we will have an overlapping megaflow with the right prefix:
10.1.0.2/16
Now we have two megaflows:
10.1.2.2/24
10.1.0.2/16
Last, suppose we have changed the ruleset again. The revalidator this
time still decides to change the actions of both megaflows instead of
deleting them.
The dpif_netdev_flow_put will search the megaflow to modify with
unmasked keys, however it might lookup the wrong megaflow as the key
10.1.2.2 matches both 10.1.2.2/24 and 10.1.0.2/16!
This patch changes the megaflow lookup code in modification path into
relying the UFID to find the correct megaflow instead of key lookup.
Falling back to a classifier lookup in case where UFID was not provided
in order to support cases where UFID was not generated from the flow
data during the flow addition.
Fixes: beb75a40fdc2 ("userspace: Switching of L3 packets in L2 pipeline")
Signed-off-by: Peng He <hepeng.0320@bytedance.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Aaron Conole was recently elected by the Open vSwitch committers.
This formalizes his status as an Open vSwitch committer.
Welcome Aaron!
Signed-off-by: Simon Horman <horms@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
13.2 was released in April and 13.1 images no longer able
to update packages:
pkg: repository FreeBSD contains packages for wrong OS version
Fix that by updating to FreeBSD 13.2.
Reported-by: David Marchand <david.marchand@redhat.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Kevin Traynor was recently elected by the Open vSwitch committers.
This formalizes his status as an Open vSwitch committer.
Welcome Kevin!
Signed-off-by: Simon Horman <horms@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Before GHA, OPTS were always passed as an argument for a *-build.sh
script. But that changed. Linux builds are using the OPTS variable
from the environment, but OSX script does not, so the options are
currently ignored.
That wasn't a big issue until now, because SSL was not available or
the build actually worked on newer branches. But GHA recently updated
OpenSSL to 3.0+ and we have deprecation warnings on branches that do
not support OpenSSL 3.0+ (branch 2.16) and that breaks the build.
Fixes: 6cb2f5a630e3 ("github: Add GitHub Actions workflow.")
Reviewed-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The json read from file is never freed in ovsdb-tool show-log
for a clustered database:
ERROR: LeakSanitizer: detected memory leaks
Direct leak of 10774760 byte(s) in 269369 object(s) allocated from:
0 0x50cc32 in malloc (ovsdb/ovsdb-tool+0x50cc32)
1 0x6e7b6b in xmalloc__ lib/util.c:140:15
2 0x6e7b6b in xmalloc lib/util.c:175:12
3 0x6494f6 in json_create lib/json.c:1489:25
4 0x64a8a7 in json_object_create lib/json.c:263:25
5 0x6525f3 in json_parser_push_object lib/json.c:1311:25
6 0x6525f3 in json_parser_input lib/json.c:1409:13
7 0x64f6c4 in json_parser_feed lib/json.c:1126:17
8 0x5694b5 in parse_body ovsdb/log.c:412:9
9 0x5694b5 in ovsdb_log_read ovsdb/log.c:477:13
10 0x54d294 in do_show_log_cluster ovsdb/ovsdb-tool.c:1069:27
11 0x54d294 in do_show_log ovsdb/ovsdb-tool.c:1115:9
12 0x63b7b1 in ovs_cmdl_run_command__ lib/command-line.c:247:17
13 0x5488a5 in main ovsdb/ovsdb-tool.c:82:5
14 0xe0eb49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49)
15 0xe0ec0a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x27c0a)
16 0x471fe4 in _start (ovsdb/ovsdb-tool+0x471fe4)
Fixes: 1b1d2e6daa56 ("ovsdb: Introduce experimental support for clustered databases.")
Reported-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
During initial read of a database file all the file transactions are
added to the transaction history. The history run with the history
size checks is only executed after the whole file is processed.
If, for some reason, the file contains way too many transactions,
this behavior may result in excessive memory consumption up to
hundreds of GBs. For example, here is a log entry about memory usage
after reading a file with 100K+ OVN NbDB transactions:
|00004|memory|INFO|95650400 kB peak resident set size after 96.9 seconds
|00005|memory|INFO|atoms:3083346 cells:1838767 monitors:0
raft-log:123309 txn-history:123307 txn-history-atoms:1647022868
In this particular case ovsdb-server allocated 95 GB of RAM in order
to accommodate 1.6 billion ovsdb atoms in the history, while only 3
million atoms are in the actual database.
Fix that by running history size checks after applying each file
transaction. This way the memory usage while reading the database
from the example stays at about 1 GB mark. History size checks are
cheap in comparison with transaction replay, so the additional calls
do not reduce performance.
We could've just moved the history run into ovsdb_txn_replay_commit(),
but it seems more organic to call it externally, since we have init()
and destroy() functions called externally as well.
Since the history run will be executed shortly after reading the
database and actual memory consumption peak is not always logged,
there seem to be no reliable way to unit test for the issue without
adding extra testing infrastructure into the code.
Fixes: 695e81502794 ("ovsdb-server: Transaction history tracking.")
Reported-at: https://bugzilla.redhat.com/2228464
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Adding an extra check to one of the ovsdb execution cases that will
verify that ovsdb-server is able to read back transactions previously
written to a database file. And also adding new execution tests
that cover previously discovered issues with size checks on sets.
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Relay servers apply updates via ovsdb_table_execute_update(). XOR
updates contain datum diffs, and datum diffs can be larger than the
type constraints. Currently, relay will fail to parse such update
into ovsdb row triggering a syntax error and a re-connection.
Fix that by relaxing the size constraints for this kind of updates.
Fixes: 026c77c58ddb ("ovsdb: New ovsdb 'relay' service model.")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
On a server side, default values are just normal values. The only
difference is that they are initialized from default atoms. They are
allocated on a separate piece of memory as any other values, so there
should not be any special treatment.
Current code doesn't apply the diff to a column with default values
after reading the file transaction and that breaks the logic.
For example, if we have a column with a set and a minimum number of
elements for a type is 1, it will be initialized with one default atom.
On mutation, new values can be added and the diff will contain only
these new values, while the column will contain both the new values
and the default atom. While reading such transaction from a file
with a diff, current code will replace the content losing the default
atom. The only case where we need to actually replace is if this row
doesn't exist and it's not actually a diff, i.e. if this row was just
created to be populated with a json content.
Fix that by removing the wrong check and not use values as a diff
in case the row doesn't exist in a database.
Fixes: 2ccd66f594f7 ("ovsdb: Use column diffs for ovsdb and raft log entries.")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Diff records in a database file may contain sets larger than a maximum
set size, so constraints should not be checked on read. They will be
checked later after applying the diff to a column.
Fixes: 2ccd66f594f7 ("ovsdb: Use column diffs for ovsdb and raft log entries.")
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2023-July/406685.html
Reported-by: Peng He <xnhp0320@gmail.com>
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
ovs-tcpdump will add mipxxx NIC, and on some systems this NIC has IPv6
address by default. For vxlan topology, mipxxx, which has IPv6
address, will be treated as tunnel port, and will got error actions.
Prevent this by clearing the auto-assigned IPv6 address. This can also
be controlled on some systems with ipv6 sysctls.
Tested on centos stream 8, and ubuntu 20.04.
Acked-by: Mike Pattrick <mkp@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Simon Jones <batmanustc@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
OVS configuration is based on port names and OpenFlow port numbers.
Names are stored in the database and translated later to OF ports.
On the datapath level, each port has a name and a datapath port number.
Port name in the database has to match datapath port name, unless it's
a tunnel port.
If a datapath port is renamed with 'ip link set DEV name NAME',
ovs-vswitchd will wake up, destroy all the OpenFlow-related structures
and clean other things up. This is because the port no longer
represents the port from a database due to a name difference.
However, ovs-vswitch will not actually remove the port from the
datapath, because it thinks that this port is no longer there. This
is happening because lookup is performed by name and the name have
changed. As a result we have a port in a datapath that is not related
to any port known to ovs-vswitchd and ovs-vswitchd can't remove it.
This port also occupies a datapath port number and prevents the port
to be added back with a new name.
Fix that by performing lookup by a datapath port number during the port
destruction. The name was used only to avoid spurious warnings in a
normal case where the port was successfully deleted by other parts of
OVS. Adding an extra flag to avoid these warnings instead.
Fixes: 02f8d6460afd ("ofproto-dpif: Query port existence by name to prevent warnings.")
Reported-at: https://github.com/openvswitch/ovs-issues/issues/284
Tested-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Acked-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This may be required by some PMDs in offload scenarios.
Fixes: e8a2b5bf92bb ("netdev-dpdk: implement flow offload with rte flow")
Signed-off-by: Ivan Malov <ivan.malov@arknetworks.am>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Currently OVS keeps track of which mirrors that each packet has been
sent to for the purpose of deduplication. However, this doesn't consider
that openflow rules can make significant changes to packets after
ingress.
For example, OVN can create OpenFlow rules that turn an echo request
into an echo response by flipping source/destination addresses and
setting the ICMP type to Reply. When a mirror is configured, only the
request gets mirrored even though a response is received.
This can cause a false impression of the actual traffic on wire if
someone inspects the mirror and doesn't see an echo reply even though
one has been sent.
This patch resets the mirrors every time a packet is modified, so
mirrors will receive every copy of a packet that is sent for output.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2155579
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
In a backtrace test with monitor the child process will be re-started
after being killed. The test doesn't wait for that to happen, so it
is possible that during the test cleanup the pid in a pid file is not
updated yet. Hence, the on-exit hook will not kill the process.
This is causing issues in Cirrus CI, because gmake on FreBSD waits for
all child processes to exit and that never happens.
Fix the issue by waiting for a new process. It's also better to exit
gracefully instead of relying on the on-exit kill.
Fixes: 759a29dc2d97 ("backtrace: Extend the backtrace functionality.")
Acked-by: Ales Musil <amusil@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Before the cleanup option, the bridge_exit() call was fairly fast,
because it didn't include any particularly long operations. However,
with the cleanup flag, this function destroys a lot of datapath
resources freeing a lot of memory, waiting on RCU and talking to
the kernel. That may take a noticeable amount of time, especially
on a busy system or under profilers/sanitizers. However, the unixctl
'exit' command replies instantly without waiting for any work to
actually be done. This may cause system test failures or other
issues where scripts expect ovs-vswitchd to exit or destroy all the
datapath resources shortly after appctl call.
Fix that by waiting for the bridge_exit() before replying to the user.
At least, all the datapath resources will actually be destroyed by
the time ovs-appctl exits.
Also moving a structure from stack to global. Seems cleaner this way.
Since we're not replying right away and it's technically possible
to have multiple clients requesting exit at the same time, storing
connections in an array.
Fixes: fe13ccdca6a2 ("vswitchd: Add --cleanup option to the 'appctl exit' command")
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Use TCA_POLICE_RATE64 if the rate cannot be expressed using 32bits.
This breaks the 32Gbps barrier. The new barrier is ~4Tbps caused by
netdev's API expressing kbps rates using 32-bit integers.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2137643
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
In preparation for supporting 64-bit rates in tc policies, move the
allocation and initialization of struct tc_police object inside
nl_msg_put_act_police(). That way, the function is now called with the
actual rates.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
It is equivalent to tc_policer_init() so remove the duplicated function.
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Currently, htb rates are capped at ~34Gbps because they are internally
expressed as 32-bit fields.
Move min and max rates to 64-bit fields and use TCA_HTB_RATE64 and
TCA_HTB_CEIL64 to configure HTC classes to break this barrier.
In order to test this, create a dummy tuntap device and set it's
speed to a very high value so we can try adding a QoS queue with big
rates.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2137619
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
tc uses these "rtab" tables to estimate the time (ticks) that it takes
to send a packet of different sizes. In preparation for the introduction
of 64-bit rates, add an argument to tc_put_rtab() to allow an external
64-bit rate.
Also use 64bits for other burst buffer calculation functions.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Instead of relying on feature bits, use the speed value directly as
maximum rate for htb and hfsc classes.
There is still a limitation with the maximum rate that we can express
with a 32-bit number in bytes/s (~ 34.3Gbps), but using the actual link speed
instead of the feature bits, we can at least use an accurate maximum for
some link speeds (such as 25Gbps) which are not supported by netdev's feature
bits.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Currently, the netdev's speed is being calculated by taking the link's
feature bits (using netdev_get_features()) and transforming them into
bps.
This mechanism can be both inaccurate and difficult to maintain, mainly
because we currently use the feature bits supported by OpenFlow which
would have to be extended to support all new feature bits of all netdev
implementations while keeping the OpenFlow API intact.
In order to expose the link speed accurately for all current and future
hardware, add a new netdev API call that allows the implementations to
provide the current and maximum link speeds in Mbps.
Internally, the logic to get the maximum supported speed still relies on
feature bits so it might still get out of sync in the future. However,
the maximum configurable speed is not used as much as the current speed
and these feature bits are not exposed through the netdev interface so
it should be easier to add more.
Use this new function instead of netdev_get_features() where the link
speed is needed.
As a consequence of this patch, link speeds of cards is properly
reported (internally in OVSDB) even if not supported by OpenFlow.
A test verifies this behavior using a tap device.
Also, in order to avoid using the old, this patch adds a checkpatch.py
warning if the old API is used.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2137567
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Previously it was not possible to set the probe interval for the
connection from a relay to the backing ovsdb-server. With this change
it is now possible using the
`ovsdb-server/set-relay-source-probe-interval` command.
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Felix Huettner <felix.huettner@mail.schwarz>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Max requested sleep time and status for a PMD thread
is logged at start up or when changed, but it can be
convenient to have a command to dump this information
explicitly.
It is envisaged that this will be expanded for individual
pmds in the future, hence adding to dpif_netdev_pmd_info().
Reviewed-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This is just cosmetic. There is no change to the tests.
Reviewed-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
other_config:pmd-maxsleep is a config option to allow
PMD thread cores to sleep under low or no load conditions.
Rename it to 'pmd-sleep-max' to allow a more structured
name and so that additional options or command can follow
the 'pmd-sleep-xyz' pattern.
Use of other_config:pmd-maxsleep is deprecated to be
removed in a future release and will result in a warning.
Reviewed-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This adds a Python version of the async DNS support added in:
771680d96 DNS: Add basic support for asynchronous DNS resolving
The above version uses the unbound C library, and this
implimentation uses the SWIG-wrapped Python version of that.
In the event that the Python unbound library is not available,
a warning will be logged and the resolve() method will just
return None. For the case where inet_parse_active() is passed
an IP address, it will not try to resolve it, so existing
behavior should be preserved in the case that the unbound
library is unavailable.
Intentional differences from the C version are as follows:
OVS_HOSTS_FILE environment variable can bet set to override
the system 'hosts' file. This is primarily to allow testing to
be done without requiring network connectivity.
Since resolution can still be done via hosts file lookup, DNS
lookups are not disabled when resolv.conf cannot be loaded.
The Python socket_util module has fallen behind its C equivalent.
The bare minimum change was done to inet_parse_active() to support
sync/async dns, as there is no equivalent to
parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
was added to bring socket_util.py up to equivalency to the C
version.
Signed-off-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Since a27d70a89 ("conntrack: add generic IP protocol support") all
the unrecognized IP protocols get handled using ct_proto_other ops
and are managed as L3 using 3 tuples.
This patch stores L4 information for SCTP in the conn_key so that
multiple conn instances, instead of one with ports zeroed, will be
created when there are multiple SCTP connections between two hosts.
It also performs crc32c check when not offloaded, and adds SCTP to
pat_enabled.
With this patch, given two SCTP association between two hosts,
tracking the connection will result in:
sctp,orig=(src=10.1.1.2,dst=10.1.1.1,sport=55884,dport=5201),
reply=(src=10.1.1.1,dst=10.1.1.2,sport=5201,dport=12345),zone=1
sctp,orig=(src=10.1.1.2,dst=10.1.1.1,sport=59874,dport=5202),
reply=(src=10.1.1.1,dst=10.1.1.2,sport=5202,dport=12346),zone=1
instead of:
sctp,orig=(src=10.1.1.2,dst=10.1.1.1,sport=0,dport=0),
reply=(src=10.1.1.1,dst=10.1.1.2,sport=0,dport=0),zone=1
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This commit adds assertions in the functions `shash_count`,
`simap_count`, and `smap_count` to ensure that the corresponding input
struct pointer is not NULL.
This ensures that if the return values of `shash_sort`, `simap_sort`,
or `smap_sort` are NULL, then the following for loops would not attempt
to access the pointer, which might result in segmentation faults or
undefined behavior.
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: James Raphael Tiovalen <jamestiotio@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The set_error function is now used regardless of whether experimental APIs
are allowed or not, so it must be defined unconditionally.
Fixes: fc06ea9a1883 ("netdev-dpdk: Add custom rx-steering configuration.")
Acked-by: Ivan Malov <ivan.malov@arknetworks.am>
Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@arknetworks.am>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Several xlate actions used in recursive translation currently store a
large amount of information on the stack. This can result in handler
threads quickly running out of stack space despite before
xlate_resubmit_resource_check() is able to terminate translation. This
patch reduces stack usage by over 3kb from several translation actions.
This patch also moves some trace function from do_xlate_actions into its
own function.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2104779
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
This narrows down spelling errors that are in the commit
subject. It also provides a subject if the subject line is
missing. The provisional subject is the name of the patch
file, which should provide some context about the patch.
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Chandan Somani <csomani@redhat.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
This will be useful for correcting possible spelling
mistakes with ease. Suggestions limited to 3 at first,
but can be made configurable in the future.
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Chandan Somani <csomani@redhat.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Single out flagged words and allow for more useful
details, like spelling suggestions.
Signed-off-by: Chandan Somani <csomani@redhat.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
In the case where routing is enabled, the bridge member of the
`vsctl_port` structs is not populated. This can cause a crash if we
attempt to access it. This patch fixes the crash by checking if the
bridge member is valid before attempting to access it. In the
`check_conflicts` function, we print both the port name and the bridge
name if routing is disabled and we only print the port name if routing
is enabled.
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: James Raphael Tiovalen <jamestiotio@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>