delta/openvswitch.git/ovsdb/ovsdb-client.c, branch master

dpdk: Allow retaining CAP_SYS_RAWIO privileges.

2023-03-22T17:56:02+00:00

Open vSwitch generally tries to let the underlying operating system
managed the low level details of hardware, for example DMA mapping,
bus arbitration, etc.  However, when using DPDK, the underlying
operating system yields control of many of these details to userspace
for management.

In the case of some DPDK port drivers, configuring rte_flow or even
allocating resources may require access to iopl/ioperm calls, which
are guarded by the CAP_SYS_RAWIO privilege on linux systems.  These
calls are dangerous, and can allow a process to completely compromise
a system.  However, they are needed in the case of some userspace
driver code which manages the hardware (for example, the mlx
implementation of backend support for rte_flow).

Here, we create an opt-in flag passed to the command line to allow
this access.  We need to do this before ever accessing the database,
because we want to drop all privileges asap, and cannot wait for
a connection to the database to be established and functional before
dropping.  There may be distribution specific ways to do capability
management as well (using for example, systemd), but they are not
as universal to the vswitchd as a flag.

Reviewed-by: Simon Horman 
Signed-off-by: Aaron Conole 
Acked-by: Flavio Leitner 
Acked-by: Gaetan Rivet 
Signed-off-by: Ilya Maximets

ovsdb: Make clients aware of relay service model.

2021-07-15T20:38:49+00:00

Clients needs to re-connect from the relay that has no connection
with the database source.  Also, relay acts similarly to the follower
from a clustered model from the consistency point of view, so it's not
suitable for leader-only connections.

Acked-by: Mark D. Gray 
Acked-by: Dumitru Ceara 
Signed-off-by: Ilya Maximets

ovsdb-client: Integrate record/replay functionality.

2021-06-07T19:03:16+00:00

This is primarily to be able to test recording of client connections.
Unit test added accordingly.

Signed-off-by: Ilya Maximets 
Acked-by: Dumitru Ceara

ovsdb-client: Fix needs-conversion when SERVER is explicitly specified.

2021-02-19T18:02:05+00:00

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 
Signed-off-by: Ilya Maximets

ovsdb-client: fix memory leak while executing database backup

2019-10-09T18:03:46+00:00

valgrind detects this leak while running functional test "ovsdb-client backup and restore"

==25401== 1,068 (240 direct, 828 indirect) bytes in 6 blocks are definitely lost in loss record 22 of 22
==25401==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25401==    by 0x449DA4: xmalloc (util.c:138)
==25401==    by 0x43012D: json_create (json.c:1451)
==25401==    by 0x43012D: json_array_create_empty (json.c:186)
==25401==    by 0x43012D: json_parser_push_array (json.c:1279)
==25401==    by 0x4303CF: json_parser_input (json.c:1407)
==25401==    by 0x4312F1: json_lex_input (json.c:991)
==25401==    by 0x43193B: json_parser_feed (json.c:1149)
==25401==    by 0x4329FA: jsonrpc_recv.part.7 (jsonrpc.c:332)
==25401==    by 0x432D3B: jsonrpc_recv (jsonrpc.c:297)
==25401==    by 0x432D3B: jsonrpc_recv_block (jsonrpc.c:402)
==25401==    by 0x4330EB: jsonrpc_transact_block (jsonrpc.c:436)
==25401==    by 0x409246: do_backup (ovsdb-client.c:2008)
==25401==    by 0x405F76: main (ovsdb-client.c:282)

the problem was in db_backup() function, where _uuid json node was detached from
its parent "row" json node, but never destroyed afterwards.

Signed-off-by: Damijan Skvarc 
Signed-off-by: Ben Pfaff

ovsdb-client: fix memory leak to prevent valgrind reporting memory leaks while running test suite

2019-10-02T14:48:07+00:00

memory leaks are reported in several tests and are expressed in a following way:

==29840== 208 (48 direct, 160 indirect) bytes in 1 blocks are definitely lost in
 loss record 43 of 44
==29840==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64
-linux.so)
==29840==    by 0x449D12: xcalloc (util.c:121)
==29840==    by 0x432949: jsonrpc_msg_from_json (jsonrpc.c:697)
==29840==    by 0x432A8F: jsonrpc_parse_received_message (jsonrpc.c:472)
==29840==    by 0x432A8F: jsonrpc_recv.part.7 (jsonrpc.c:338)
==29840==    by 0x4338F7: jsonrpc_recv (jsonrpc.c:1139)
==29840==    by 0x4338F7: jsonrpc_session_recv (jsonrpc.c:1112)
==29840==    by 0x40719B: do_wait (ovsdb-client.c:2463)
==29840==    by 0x405F76: main (ovsdb-client.c:282)

Signed-off-by: Damijan Skvarc 
Signed-off-by: Ben Pfaff

ovsdb-client: fix memory leak in do_needs_conversion() and do_convert()

2019-10-01T16:10:29+00:00

Memory leak itself is not so important, however the problem is that
it is caused by forgetting to close rpc channel which might in
a long term lead to the leak of system resources.

Memory leak is reported by Valgrin running test suite and is expressed as:

==29472== 784 (600 direct, 184 indirect) bytes in 1 blocks are definitely lost in loss record 23 of 23
==29472==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29472==    by 0x449D32: xcalloc (util.c:121)
==29472==    by 0x432147: jsonrpc_open (jsonrpc.c:87)
==29472==    by 0x40ABBE: open_jsonrpc (ovsdb-client.c:528)
==29472==    by 0x40ABBE: open_rpc (ovsdb-client.c:143)
==29472==    by 0x40AE50: do_needs_conversion (ovsdb-client.c:1670)
==29472==    by 0x405F76: main (ovsdb-client.c:282)

==29464== 784 (600 direct, 184 indirect) bytes in 1 blocks are definitely lost in loss record 23 of 23
==29464==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29464==    by 0x449D32: xcalloc (util.c:121)
==29464==    by 0x432147: jsonrpc_open (jsonrpc.c:87)
==29464==    by 0x40ABBE: open_jsonrpc (ovsdb-client.c:528)
==29464==    by 0x40ABBE: open_rpc (ovsdb-client.c:143)
==29464==    by 0x40AF5A: do_convert (ovsdb-client.c:1644)
==29464==    by 0x405F76: main (ovsdb-client.c:282)

Signed-off-by: Damijan Skvarc 
Signed-off-by: Ben Pfaff

ovsdb-client: fix memory leak in is_database_clustered() function.

2019-09-30T20:37:36+00:00

Memory leak is reported while running test suite. It is evidenced with the
following report:

==18447== 1,868 (48 direct, 1,820 indirect) bytes in 1 blocks are definitely lost in loss record 45 of 45
==18447==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18447==    by 0x449C02: xcalloc (util.c:121)
==18447==    by 0x432949: jsonrpc_msg_from_json (jsonrpc.c:697)
==18447==    by 0x432A8F: jsonrpc_parse_received_message (jsonrpc.c:472)
==18447==    by 0x432A8F: jsonrpc_recv.part.7 (jsonrpc.c:338)
==18447==    by 0x432D0B: jsonrpc_recv (jsonrpc.c:297)
==18447==    by 0x432D0B: jsonrpc_recv_block (jsonrpc.c:402)
==18447==    by 0x4330BB: jsonrpc_transact_block (jsonrpc.c:436)
==18447==    by 0x40A7C1: is_database_clustered (ovsdb-client.c:1624)
==18447==    by 0x40AE3F: do_needs_conversion (ovsdb-client.c:1670)
==18447==    by 0x405F76: main (ovsdb-client.c:282)

Signed-off-by: Damijan Skvarc 
Signed-off-by: Ben Pfaff

ovsdb-client: Free ovsdb_schema

2019-09-19T16:23:54+00:00

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 
Signed-off-by: Yifeng Sun 
Signed-off-by: Ben Pfaff

ovsdb-monitor: Support monitor_cond_since.

2019-02-28T18:26:18+00:00

Support the new monitor method monitor_cond_since so that a client
can request monitoring start from a specific point instead of always
from beginning. This will reduce the cost at scenarios when server
is restarted/failed-over but client still has all existing data. In
these scenarios only new changes (and in most cases no change) needed
to be transfered to client. When ovsdb-server restarted, history
transactions are read from disk file; when ovsdb-server failed over,
history transactions exists already in the memory of the new server.

There are situations that the requested transaction may not be found.
For example, a transaction that is too old and has been discarded
from the maintained history list in memory, or the transactions on
disk has been compacted during ovsdb compaction. In those situations
the server fall backs to transfer all data start from begining.

For more details of the protocol change, see
Documentation/ref/ovsdb-server.7.rst.

This change includes both server side and ovsdb-client side changes
with the new protocol. IDLs using this capability will be added in
future patches.

Now the feature takes effect only for cluster mode of ovsdb-server,
because cluster mode is the only mode that supports unique transcation
uuid today. For other modes, the monitor_cond_since always fall back
to transfer all data with found = false. Support for those modes can
be added in the future.

Signed-off-by: Han Zhou 
Signed-off-by: Ben Pfaff