Types for UUID columns that are not references (e.g. version column)
may end up with the refType not initialized. At the same time, some
functions use the value during the type comparison, which may result
in a false negative type check:
WARNING: MemorySanitizer: use-of-uninitialized-value
0 0x75abf7 in ovsdb_base_type_equals lib/ovsdb-types.c:321:16
1 0x75f899 in ovsdb_type_equals lib/ovsdb-types.c:626:12
2 0x4fc607 in ovsdb_convert_table ovsdb/file.c:316:13
3 0x4fb5ec in ovsdb_convert ovsdb/file.c:388:17
4 0x598bcf in ovsdb_trigger_try ovsdb/trigger.c:313:25
5 0x596902 in ovsdb_trigger_init ovsdb/trigger.c:66:12
6 0x5189e8 in ovsdb_jsonrpc_trigger_create ovsdb/jsonrpc-server.c:1247:27
7 0x51473d in ovsdb_jsonrpc_session_got_request ovsdb/jsonrpc-server.c:1112:13
8 0x512ea2 in ovsdb_jsonrpc_session_run ovsdb/jsonrpc-server.c:677:17
9 0x50d67d in ovsdb_jsonrpc_session_run_all ovsdb/jsonrpc-server.c:700:21
10 0x50cc49 in ovsdb_jsonrpc_server_run ovsdb/jsonrpc-server.c:522:9
11 0x4d756f in main_loop ovsdb/ovsdb-server.c:330:9
12 0x4c4e52 in main ovsdb/ovsdb-server.c:890:5
13 0x7f42bb in __libc_start_call_main
14 0x7f42bb in __libc_start_main@GLIBC_2.2.5
15 0x432b64 in _start (ovsdb/ovsdb-server+0x432b64)
Fix the initialization function to always set the refType to some
value. Using the "strong" as we don't have an UNSPEC value in the
enumeration. It will not be meaningful unless the refTable is also
set, in which case it will be properly updated, we just need the
value to be the same for all the columns that are not references.
Fixes: e0e4266a90a2 ("ovsdb-types: Add functions to compare types for equality.")
Acked-by: Mike Pattrick <mkp@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Currently ovsdb-server is using shallow copies of some JSON objects
by keeping a reference counter. JSON string objects are also used
directly as ovsdb atoms in database rows to avoid extra copies.
Taking this approach one step further ovsdb_datum objects can also
be mostly deduplicated by postponing the copy until it actually
needed. datum object itself contains a type and 2 pointers to
data arrays. Adding a one more pointer to a reference counter
we may create a shallow copy of the datum by simply copying type
and pointers and increasing the reference counter.
Before modifying the datum, special function needs to be called
to perform an actual copy of the object, a.k.a. unshare it.
Most of the datum modifications are performed inside the special
functions in ovsdb-data.c, so that is not very hard to track.
A few places like ovsdb-server.c and column mutations are accessing
and changing the data directly, so a few extra unshare() calls
has to be added there.
This change doesn't affect the maximum memory consumption too much,
because most of the copies are short-living. However, not actually
performing these copies saves up to 40% of CPU time on operations
with large sets.
Reported-at: https://bugzilla.redhat.com/2069089
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Several OVS structs contain embedded named unions, like this:
struct {
...
union {
...
} u;
};
C11 standardized a feature that many compilers already implemented
anyway, where an embedded union may be unnamed, like this:
struct {
...
union {
...
};
};
This is more convenient because it allows the programmer to omit "u."
in many places. OVS already used this feature in several places. This
commit embraces it in several others.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
Tested-by: Alin Gabriel Serdean <aserdean@ovn.org>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
To easily allow both in- and out-of-tree building of the Python
wrapper for the OVS JSON parser (e.g. w/ pip), move json.h to
include/openvswitch. This also requires moving lib/{hmap,shash}.h.
Both hmap.h and shash.h were #include-ing "util.h" even though the
headers themselves did not use anything from there, but rather from
include/openvswitch/util.h. Fixing that required including util.h
in several C files mostly due to OVS_NOT_REACHED and things like
xmalloc.
Signed-off-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This allows other libraries to use util.h that has already
defined NOT_REACHED.
Signed-off-by: Harold Lim <haroldl@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Some of the uses for the formerly supported regular expression constraints
were simply to limit values to those in a set of allowed values.
This commit adds support for that kind of simple enumeration constraint.
Regular expression constraints have caused nothing but trouble due to the
lack of a ubiquitous regular expression library. PCRE is *almost*
everywhere, but it has different versions, and different features, and
different bugs, in different places. It is more trouble than it is worth.
So this commit drops support.
It is natural to write "abc" in place of ["set",["abc"]] and vice versa.
I cannot think of a reason not to support this, and it can make reading
and writing OVSDB files and transactions easier, so support it.
A "min" value greater than 1 is problematic for the database. There is no
reasonable way to synthesize a default value for such a column: keys in a
set or map must unique, so the database cannot, say, simply set a set of
3 or more integers to [0, 0, 0].
This should have no effect on the vswitch in practice because it does not
have any columns that require more than one element.
