Ip full ip/v3/p9 by numansiddique · Pull Request #1 · numansiddique/ovn

numansiddique · 2020-04-14T12:50:57Z

No description provided.

venkataanil · 2020-04-14T12:54:19Z

                local_binding_add_child(lbinding, child);
+                if (b_ctx_out->tracked_dp_bindings) {
+                    tracked_binding_datapath_lport_add(
+                        b_ctx_out->tracked_dp_bindings, pb, false);


Why are we not calling "local_datapath_update_lport_count()" here to increase the port count in local datapath?

Good catch.

venkataanil · 2020-04-14T13:20:56Z

 runtime_data_ovs_interface_handler(struct engine_node *node, void *data)
 {
    struct ed_type_runtime_data *rt_data = data;
+    struct ed_type_runtime_tracked_data *tracked_data = node->tracked_data;


call
en_runtime_clear_tracked_data(node->tracked_data);

here as well

No need. engine will take care of clearing the tracked data.

venkataanil · 2020-04-14T13:21:32Z

    struct binding_ctx_in b_ctx_in;
    struct binding_ctx_out b_ctx_out;
    init_binding_ctx(node, rt_data, &b_ctx_in, &b_ctx_out);
+    tracked_data->tracked = true;


call
en_runtime_clear_tracked_data(node->tracked_data);

here as well

venkataanil · 2020-04-14T13:21:51Z


+    struct ed_type_runtime_tracked_data *tracked_data = node->tracked_data;
+    tracked_data->tracked = true;
+    b_ctx_out.tracked_dp_bindings = &tracked_data->tracked_dp_bindings;


Why u missed
b_ctx_out.local_lports_changed = &tracked_data->local_lports_changed;

That's because it is meant to track ovs interfaces with iface-id set.
This is required to update the condition monitoring.

For example, in the below sequence ..
1)ovn-nbctl ls-add sw0
2)ovs-vsctl add-port br-int p1 --
set Interface p1 external_ids:iface-id=sw0-port1
3)ovn-nbctl lsp-add sw0 sw0-port1

We step 3 will add the local binding and claim the port.
Step 2 will run runtime_data_ovs_interface_handler, but local binding is not created as port doesn't exist in SBDB
Step 3 will result in runtime_data_sb_port_binding_handler, which adds local binding. So in this case, we need to update b_ctx_out.local_lports_changed as this flag is used in flow_output_runtime_data_handler

Am I missing anything here?

local_binding is created in step 2.

…and binding_ctx_out. No functional changes are introduced in this patch. Signed-off-by: Numan Siddique <numans@ovn.org>

… state. This patch adds a new data structure - 'struct local_binding' which represents a probable local port binding. A new object of this structure is creared for each interface present in the integration bridge (br-int) with the external_ids:iface-id set. This struct has 2 main fields - 'struct ovsrec_interface *' and 'struct sbrec_port_binding *'. These fields are updated during port claim and release. A shash of the local bindings is maintained with the 'iface-id' as the hash key in the runtime data of the incremental processing engine. This patch helps in the upcoming patch to add incremental processing support for OVS interface and SB port binding changes. Signed-off-by: Numan Siddique <numans@ovn.org>

…data. This patch handles SB port binding changes and OVS interface changes incrementally in the runtime_data stage which otherwise would have resulted in calls to binding_run(). Prior to this patch, port binding changes were handled differently. The changes were only evaluated to see if they need full recompute or they can be ignored. With this patch, the runtime data is updated with the changes (both SB port binding and OVS interface) and ports are claimed/released in the handlers itself, avoiding the need to trigger recompute of runtime data stage. Signed-off-by: Numan Siddique <numans@ovn.org>

This patch adds partial support of incremental processing of datapath binding. If a datapath is deleted, then a full recompute is triggered if that datapath is present in the 'local_datapaths' hmap of runtime data. Signed-off-by: Numan Siddique <numans@ovn.org>

… actions have changed. If ofctrl_check_and_add_flow(F') is called where flow F' has match-actions (M, A2) and if there already exists a flow F with match-actions (M, A1) in the desired flow table, then this function doesn't update the existing flow F with new actions actions A2. This patch is required for the upcoming patch in this series which adds incremental processing for OVS interface in the flow output stage. Since we will be not be clearing the flow output data if these changes are handled incrementally, some of the existing flows will be updated with new actions. One such example would be flows in physical table OFTABLE_LOCAL_OUTPUT (table 33). And this patch is required to update such flows. Otherwise we will have incomplete actions installed. Signed-off-by: Numan Siddique <numans@ovn.org>

…put stage. This patch handles ct zone changes and OVS interface changes incrementally in the flow output stage. Any changes to ct zone can be handled by running physical_run() instead of running flow_output_run(). And any changes to OVS interfaces can be either handled incrementally (for OVS interfaces representing VIFs) or just running physical_run() (for tunnel and other types of interfaces). To better handle this, a new engine node 'physical_flow_changes' is added which handles changes to ct zone and OVS interfaces. Signed-off-by: Numan Siddique <numans@ovn.org>

With this patch, an engine node which is an input to another engine node can provide the tracked data. The parent of this engine node can handle this tracked data incrementally. At the end of the engine_run(), the tracked data of the nodes are cleared. Signed-off-by: Numan Siddique <numans@ovn.org>

In order to handle runtime data changes incrementally, the flow outut runtime data handle should know the changed runtime data. Runtime data now tracks the changed data for any OVS interface and SB port binding changes. The tracked data contains a hmap of tracked datapaths (which changed during runtime data processing. The flow outout runtime_data handler in this patch doesn't do much with the tracked data. It returns false if there is tracked data available so that flow_output run is called. If no tracked data is available then there is no need for flow computation and the handler returns true. Next patch in the series processes the tracked data incrementally. Co-Authored-by: Venkata Anil <anilvenkata@redhat.com> Signed-off-by: Venkata Anil <anilvenkata@redhat.com> Signed-off-by: Numan Siddique <numans@ovn.org>

This patch processes the logical flows of tracked datapaths and tracked logical ports. To handle the tracked logical port changes, reference of logical flows to port bindings is maintained. Co-Authored-by: Numan Siddique <numans@ovn.org> Signed-off-by: Venkata Anil <anilvenkata@redhat.com> Signed-off-by: Numan Siddique <numans@ovn.org>

The 'nexthop' that passed to ic_route_hash() is not fully initialized in get_nexthop_from_lport_addresses(). 'nexthop' has type of 'struct v46_ip' which contains a union to share space for ipv4 and ipv6 address. If only ipv4 initialized where is a plenty of uninitialized space that goes to hash_bytes(nexthop, sizeof *nexthop, basis). Impact: there are two places where this function is called. 1. In add_to_routes_ad(), the nexthop is initialized in parse_route() before calling get_nexthop_from_lport_addresses(), luckily. 2. In add_network_to_routes_ad(), we are unlucky. When a directly connected network of a router is found to be advertised, if the route already existed in the global IC-SB, it may not be found due to the hash difference, and results in the existing route being deleted and the same one recreated, unnecessarily. This patch fixes the problem by initializing the struct to zero before setting the fields. From Ilya's report: > Report from MemorySanitizer: > > ==3074629==WARNING: MemorySanitizer: use-of-uninitialized-value > #0 0x67177e in mhash_add__ ovs/./lib/hash.h:66:9 > #1 0x671668 in mhash_add ovs/./lib/hash.h:78:12 > #2 0x6701e9 in hash_bytes ovs/lib/hash.c:38:16 > #3 0x524b4a in add_network_to_routes_ad ic/ovn-ic.c:1095:5 > ovn-org#4 0x51eea3 in route_run ic/ovn-ic.c:1424:21 > ovn-org#5 0x51887b in main ic/ovn-ic.c:1674:17 > ovn-org#6 0x7fd4ce7871a2 in __libc_start_main > ovn-org#7 0x49c90d in _start (ic/ovn-ic+0x49c90d) > > Uninitialized value was created by an allocation of 'nexthop' in the > stack frame of function 'add_network_to_routes_ad' > #0 0x5245f0 in add_network_to_routes_ad ic/ovn-ic.c:1069 Reported-by: Ilya Maximets <i.maximets@ovn.org> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2020-October/376160.html Fixes: 57b347c ("ovn-ic: Route advertisement.") Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Han Zhou <hzhou@ovn.org>

'child_port_list' is an array of pointers that should be freed too. Direct leak of 30 byte(s) in 6 object(s) allocated from: #0 0x501fff in malloc (/tests/ovstest+0x501fff) #1 0x6227e6 in xmalloc /lib/util.c:138:15 #2 0x6228b8 in xmemdup0 /lib/util.c:168:15 #3 0x8183d6 in parse_fwd_group_action /lib/actions.c:3374:30 ovn-org#4 0x814b6e in parse_action /lib/actions.c:3610:9 ovn-org#5 0x8139ef in parse_actions /lib/actions.c:3637:14 ovn-org#6 0x8136a3 in ovnacts_parse /lib/actions.c:3672:9 ovn-org#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3699:5 ovn-org#8 0x53a979 in test_parse_actions /tests/test-ovn.c:1372:21 ovn-org#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17 ovn-org#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5 ovn-org#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17 ovn-org#12 0x537359 in main /tests/ovstest.c:133:9 ovn-org#13 0x7f06978f21a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) CC: Manoj Sharma <manoj.sharma@nutanix.com> Fixes: edb2400 ("Forwarding group to load balance l2 traffic with liveness detection") Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Numan Siddique <numans@ovn.org>

'dsts' should be freed in case of any error. Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x502378 in realloc (/tests/ovstest+0x502378) #1 0x622826 in xrealloc /lib/util.c:149:9 #2 0x8194f4 in parse_select_action /lib/actions.c:1185:20 #3 0x814f49 in parse_set_action /lib/actions.c:3499:13 ovn-org#4 0x814341 in parse_action /lib/actions.c:3554:9 ovn-org#5 0x8139ef in parse_actions /lib/actions.c:3643:14 ovn-org#6 0x8136a3 in ovnacts_parse /lib/actions.c:3678:9 ovn-org#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3705:5 ovn-org#8 0x53a4e8 in test_parse_actions /tests/test-ovn.c:1321:17 ovn-org#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17 ovn-org#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5 ovn-org#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17 ovn-org#12 0x537359 in main /tests/ovstest.c:133:9 ovn-org#13 0x7f9ce05ba1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) CC: Han Zhou <hzhou@ovn.org> Fixes: 85b3544 ("ovn-controller: A new action "select".") Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Numan Siddique <numans@ovn.org>

'parse_ofp_meter_mod_str' allocates space for meter.bands that should be freed. Direct leak of 448 byte(s) in 7 object(s) allocated from: #0 0x52100f in malloc (/controller/ovn-controller+0x52100f) #1 0x7523a6 in xmalloc /lib/util.c:138:15 #2 0x6fd079 in ofpbuf_init /lib/ofpbuf.c:123:26 #3 0x6cba27 in parse_ofp_meter_mod_str /lib/ofp-meter.c:779:5 ovn-org#4 0x5705b8 in add_meter_string /controller/ofctrl.c:1674:19 ovn-org#5 0x56f736 in ofctrl_put /controller/ofctrl.c:2105:13 ovn-org#6 0x59aebb in main /controller/ovn-controller.c:2627:25 ovn-org#7 0x7f07873251a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) CC: Guoshuai Li <ligs@dtdream.com> Fixes: c25094b ("ovn: OVN Support QoS meter") Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Numan Siddique <numans@ovn.org>

'smap_clear()' doesn't free allocated memory, but 'smap_clone()' re-initializes hash map clearing internal pointers and leaking this memory. 'smap_destroy()' should be used instead. Also, all the records and array of datapaths should be freed on destruction of a cache entry. Direct leak of 16 byte(s) in 2 object(s) allocated from: #0 0x5211c7 in calloc (/controller/ovn-controller+0x5211c7) #1 0x752364 in xcalloc /lib/util.c:121:31 #2 0x576e76 in sync_dns_cache /controller/pinctrl.c:2517:25 #3 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5 ovn-org#4 0x59b06c in main /controller/ovn-controller.c:2642:25 ovn-org#5 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) Indirect leak of 26 byte(s) in 2 object(s) allocated from: #0 0x52100f in malloc (/controller/ovn-controller+0x52100f) #1 0x7523d6 in xmalloc /lib/util.c:138:15 #2 0x7524a8 in xmemdup0 /lib/util.c:168:15 #3 0x73d8fc in smap_clone /lib/smap.c:314:45 ovn-org#4 0x576e2f in sync_dns_cache /controller/pinctrl.c:2513:13 ovn-org#5 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5 ovn-org#6 0x59b06c in main /controller/ovn-controller.c:2642:25 ovn-org#7 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) Fixes: 6b72068 ("ovn-controller: Add a new thread in pinctrl module to handle packet-ins.") Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Numan Siddique <numans@ovn.org>

shash contains pointers to the data that should be freed. Direct leak of 32 byte(s) in 2 object(s) allocated from: #0 0x52100f in malloc (/controller/ovn-controller+0x52100f) #1 0x752436 in xmalloc /lib/util.c:138:15 #2 0x5a2f0b in add_pending_ct_zone_entry /controller/ovn-controller.c:548:45 #3 0x5a2d1d in update_ct_zones /controller/ovn-controller.c:668:9 ovn-org#4 0x59d8c6 in en_ct_zones_run /controller/ovn-controller.c:1495:5 ovn-org#5 0x5dade4 in engine_run /lib/inc-proc-eng.c:377:9 ovn-org#6 0x59adf4 in main /controller/ovn-controller.c ovn-org#7 0x7f0799ef41a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) CC: xu rong <xu.rong@zte.com.cn> Fixes: 252e164 ("ovn-controller: pending_ct_zones should be destroyed") Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Numan Siddique <numans@ovn.org>

When a port binding of type "l3gateway" is claimed its remote peer port_binding is also stored in local_datapath.peer_ports[].remote. If the remote peer port_binding is deleted first (i.e., before the local "l3gateway" one) then we need to remove the complete local_datapath.peer_ports[] entry in order to avoid ending up using dangling pointers to already freed port bindings. Also, properly reset local_datapath->has_local_l3gateway in remove_pb_from_local_datapath(). Ilya reported this issue found by AddressSanitizer during his testing: ==1816017==ERROR: AddressSanitizer: heap-use-after-free on address 0x6140000cb170 at pc 0x0000005ab574 bp 0x7fff68925a30 sp 0x7fff68925a28 READ of size 8 at 0x6140000cb170 thread T0 #0 0x5ab573 in put_replace_chassis_mac_flows git/ovn/controller/physical.c:550:9 #1 0x5a65eb in consider_port_binding git/ovn/controller/physical.c:1168:13 #2 0x5a8764 in physical_run git/ovn/controller/physical.c:1607:9 #3 0x5a0064 in flow_output_physical_flow_changes_handler git/ovn/controller/ovn-controller.c:2127:9 ovn-org#4 0x5db423 in engine_compute git/ovn/lib/inc-proc-eng.c:306:18 ovn-org#5 0x5dae1f in engine_run_node git/ovn/lib/inc-proc-eng.c:352:14 ovn-org#6 0x5dac74 in engine_run git/ovn/lib/inc-proc-eng.c:377:9 ovn-org#7 0x59ad64 in main git/ovn/controller/ovn-controller.c ovn-org#8 0x7f39fa6491a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) ovn-org#9 0x480b2d in _start (git/ovn/controller/ovn-controller+0x480b2d) 0x6140000cb170 is located 304 bytes inside of 408-byte region [0x6140000cb040,0x6140000cb1d8) freed by thread T0 here: #0 0x520d07 in free (git/ovn/controller/ovn-controller+0x520d07) #1 0x712de7 in ovsdb_idl_db_track_clear git/ovs/lib/ovsdb-idl.c:1984:21 #2 0x59b5cd in main git/ovn/controller/ovn-controller.c:2762:9 #3 0x7f39fa6491a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) Reported-by: Ilya Maximets <i.maximets@ovn.org> Fixes: 354bdba ("ovn-controller: I-P for SB port binding and OVS interface in runtime_data.") Tested-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Numan Siddique <numans@ovn.org>

When a port binding of type "l3gateway" is claimed its remote peer port_binding is also stored in local_datapath.peer_ports[].remote. If the remote peer port_binding is deleted first (i.e., before the local "l3gateway" one) then we need to remove the complete local_datapath.peer_ports[] entry in order to avoid ending up using dangling pointers to already freed port bindings. Also, properly reset local_datapath->has_local_l3gateway in remove_pb_from_local_datapath(). Ilya reported this issue found by AddressSanitizer during his testing: ==1816017==ERROR: AddressSanitizer: heap-use-after-free on address 0x6140000cb170 at pc 0x0000005ab574 bp 0x7fff68925a30 sp 0x7fff68925a28 READ of size 8 at 0x6140000cb170 thread T0 #0 0x5ab573 in put_replace_chassis_mac_flows git/ovn/controller/physical.c:550:9 #1 0x5a65eb in consider_port_binding git/ovn/controller/physical.c:1168:13 #2 0x5a8764 in physical_run git/ovn/controller/physical.c:1607:9 #3 0x5a0064 in flow_output_physical_flow_changes_handler git/ovn/controller/ovn-controller.c:2127:9 ovn-org#4 0x5db423 in engine_compute git/ovn/lib/inc-proc-eng.c:306:18 ovn-org#5 0x5dae1f in engine_run_node git/ovn/lib/inc-proc-eng.c:352:14 ovn-org#6 0x5dac74 in engine_run git/ovn/lib/inc-proc-eng.c:377:9 ovn-org#7 0x59ad64 in main git/ovn/controller/ovn-controller.c ovn-org#8 0x7f39fa6491a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) ovn-org#9 0x480b2d in _start (git/ovn/controller/ovn-controller+0x480b2d) 0x6140000cb170 is located 304 bytes inside of 408-byte region [0x6140000cb040,0x6140000cb1d8) freed by thread T0 here: #0 0x520d07 in free (git/ovn/controller/ovn-controller+0x520d07) #1 0x712de7 in ovsdb_idl_db_track_clear git/ovs/lib/ovsdb-idl.c:1984:21 #2 0x59b5cd in main git/ovn/controller/ovn-controller.c:2762:9 #3 0x7f39fa6491a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) Reported-by: Ilya Maximets <i.maximets@ovn.org> Fixes: 354bdba ("ovn-controller: I-P for SB port binding and OVS interface in runtime_data.") Signed-off-by: Dumitru Ceara <dceara@redhat.com> (cherry-picked from master commit 2ba8b95)

The 'nexthop' that passed to ic_route_hash() is not fully initialized in get_nexthop_from_lport_addresses(). 'nexthop' has type of 'struct v46_ip' which contains a union to share space for ipv4 and ipv6 address. If only ipv4 initialized where is a plenty of uninitialized space that goes to hash_bytes(nexthop, sizeof *nexthop, basis). Impact: there are two places where this function is called. 1. In add_to_routes_ad(), the nexthop is initialized in parse_route() before calling get_nexthop_from_lport_addresses(), luckily. 2. In add_network_to_routes_ad(), we are unlucky. When a directly connected network of a router is found to be advertised, if the route already existed in the global IC-SB, it may not be found due to the hash difference, and results in the existing route being deleted and the same one recreated, unnecessarily. This patch fixes the problem by initializing the struct to zero before setting the fields. From Ilya's report: > Report from MemorySanitizer: > > ==3074629==WARNING: MemorySanitizer: use-of-uninitialized-value > #0 0x67177e in mhash_add__ ovs/./lib/hash.h:66:9 > #1 0x671668 in mhash_add ovs/./lib/hash.h:78:12 > #2 0x6701e9 in hash_bytes ovs/lib/hash.c:38:16 > #3 0x524b4a in add_network_to_routes_ad ic/ovn-ic.c:1095:5 > ovn-org#4 0x51eea3 in route_run ic/ovn-ic.c:1424:21 > ovn-org#5 0x51887b in main ic/ovn-ic.c:1674:17 > ovn-org#6 0x7fd4ce7871a2 in __libc_start_main > ovn-org#7 0x49c90d in _start (ic/ovn-ic+0x49c90d) > > Uninitialized value was created by an allocation of 'nexthop' in the > stack frame of function 'add_network_to_routes_ad' > #0 0x5245f0 in add_network_to_routes_ad ic/ovn-ic.c:1069 Reported-by: Ilya Maximets <i.maximets@ovn.org> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2020-October/376160.html Fixes: 57b347c ("ovn-ic: Route advertisement.") Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Han Zhou <hzhou@ovn.org>

'child_port_list' is an array of pointers that should be freed too. Direct leak of 30 byte(s) in 6 object(s) allocated from: #0 0x501fff in malloc (/tests/ovstest+0x501fff) #1 0x6227e6 in xmalloc /lib/util.c:138:15 #2 0x6228b8 in xmemdup0 /lib/util.c:168:15 #3 0x8183d6 in parse_fwd_group_action /lib/actions.c:3374:30 ovn-org#4 0x814b6e in parse_action /lib/actions.c:3610:9 ovn-org#5 0x8139ef in parse_actions /lib/actions.c:3637:14 ovn-org#6 0x8136a3 in ovnacts_parse /lib/actions.c:3672:9 ovn-org#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3699:5 ovn-org#8 0x53a979 in test_parse_actions /tests/test-ovn.c:1372:21 ovn-org#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17 ovn-org#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5 ovn-org#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17 ovn-org#12 0x537359 in main /tests/ovstest.c:133:9 ovn-org#13 0x7f06978f21a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) CC: Manoj Sharma <manoj.sharma@nutanix.com> Fixes: edb2400 ("Forwarding group to load balance l2 traffic with liveness detection") Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Numan Siddique <numans@ovn.org> (cherry-picked from master commit 9443464)

'dsts' should be freed in case of any error. Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x502378 in realloc (/tests/ovstest+0x502378) #1 0x622826 in xrealloc /lib/util.c:149:9 #2 0x8194f4 in parse_select_action /lib/actions.c:1185:20 #3 0x814f49 in parse_set_action /lib/actions.c:3499:13 ovn-org#4 0x814341 in parse_action /lib/actions.c:3554:9 ovn-org#5 0x8139ef in parse_actions /lib/actions.c:3643:14 ovn-org#6 0x8136a3 in ovnacts_parse /lib/actions.c:3678:9 ovn-org#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3705:5 ovn-org#8 0x53a4e8 in test_parse_actions /tests/test-ovn.c:1321:17 ovn-org#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17 ovn-org#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5 ovn-org#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17 ovn-org#12 0x537359 in main /tests/ovstest.c:133:9 ovn-org#13 0x7f9ce05ba1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) CC: Han Zhou <hzhou@ovn.org> Fixes: 85b3544 ("ovn-controller: A new action "select".") Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Numan Siddique <numans@ovn.org> (cherry-picked from master commit 18141db)

'parse_ofp_meter_mod_str' allocates space for meter.bands that should be freed. Direct leak of 448 byte(s) in 7 object(s) allocated from: #0 0x52100f in malloc (/controller/ovn-controller+0x52100f) #1 0x7523a6 in xmalloc /lib/util.c:138:15 #2 0x6fd079 in ofpbuf_init /lib/ofpbuf.c:123:26 #3 0x6cba27 in parse_ofp_meter_mod_str /lib/ofp-meter.c:779:5 ovn-org#4 0x5705b8 in add_meter_string /controller/ofctrl.c:1674:19 ovn-org#5 0x56f736 in ofctrl_put /controller/ofctrl.c:2105:13 ovn-org#6 0x59aebb in main /controller/ovn-controller.c:2627:25 ovn-org#7 0x7f07873251a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) CC: Guoshuai Li <ligs@dtdream.com> Fixes: c25094b ("ovn: OVN Support QoS meter") Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Numan Siddique <numans@ovn.org> (cherry-picked from master commit d058d9a)

'smap_clear()' doesn't free allocated memory, but 'smap_clone()' re-initializes hash map clearing internal pointers and leaking this memory. 'smap_destroy()' should be used instead. Also, all the records and array of datapaths should be freed on destruction of a cache entry. Direct leak of 16 byte(s) in 2 object(s) allocated from: #0 0x5211c7 in calloc (/controller/ovn-controller+0x5211c7) #1 0x752364 in xcalloc /lib/util.c:121:31 #2 0x576e76 in sync_dns_cache /controller/pinctrl.c:2517:25 #3 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5 ovn-org#4 0x59b06c in main /controller/ovn-controller.c:2642:25 ovn-org#5 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) Indirect leak of 26 byte(s) in 2 object(s) allocated from: #0 0x52100f in malloc (/controller/ovn-controller+0x52100f) #1 0x7523d6 in xmalloc /lib/util.c:138:15 #2 0x7524a8 in xmemdup0 /lib/util.c:168:15 #3 0x73d8fc in smap_clone /lib/smap.c:314:45 ovn-org#4 0x576e2f in sync_dns_cache /controller/pinctrl.c:2513:13 ovn-org#5 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5 ovn-org#6 0x59b06c in main /controller/ovn-controller.c:2642:25 ovn-org#7 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) Fixes: 6b72068 ("ovn-controller: Add a new thread in pinctrl module to handle packet-ins.") Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Numan Siddique <numans@ovn.org> (cherry-picked from master commit 79b946d)

shash contains pointers to the data that should be freed. Direct leak of 32 byte(s) in 2 object(s) allocated from: #0 0x52100f in malloc (/controller/ovn-controller+0x52100f) #1 0x752436 in xmalloc /lib/util.c:138:15 #2 0x5a2f0b in add_pending_ct_zone_entry /controller/ovn-controller.c:548:45 #3 0x5a2d1d in update_ct_zones /controller/ovn-controller.c:668:9 ovn-org#4 0x59d8c6 in en_ct_zones_run /controller/ovn-controller.c:1495:5 ovn-org#5 0x5dade4 in engine_run /lib/inc-proc-eng.c:377:9 ovn-org#6 0x59adf4 in main /controller/ovn-controller.c ovn-org#7 0x7f0799ef41a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) CC: xu rong <xu.rong@zte.com.cn> Fixes: 252e164 ("ovn-controller: pending_ct_zones should be destroyed") Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Numan Siddique <numans@ovn.org> (cherry-picked from master commit 11bd9d3)

This is benign but AddressSanitizer was complaining about it: Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7fa93cd6d667 in __interceptor_malloc (/lib64/libasan.so.6+0xb0667) #1 0x1be8d3e in xmalloc__ lib/util.c:137 #2 0x1be8e1a in xmalloc lib/util.c:172 #3 0x1b799d3 in json_create lib/json.c:1451 ovn-org#4 0x1b74314 in json_integer_create lib/json.c:263 ovn-org#5 0x1b7d38a in jsonrpc_create_id lib/jsonrpc.c:563 ovn-org#6 0x1b7d3a5 in jsonrpc_create_request lib/jsonrpc.c:570 ovn-org#7 0x1b8d851 in ovsdb_cs_send_transaction lib/ovsdb-cs.c:1376 ovn-org#8 0x40b017 in northd_send_output_only_data_request northd/ovn-northd-ddlog.c:290 ovn-org#9 0x40c802 in northd_run northd/ovn-northd-ddlog.c:568 ovn-org#10 0x410225 in main northd/ovn-northd-ddlog.c:1289 ovn-org#11 0x7fa93c4a9081 in __libc_start_main ../csu/libc-start.c:308 Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Ben Pfaff <blp@ovn.org>

UB Sanitizer reports: controller/pinctrl.c:4607:17: runtime error: member access within misaligned address 0x7efe1c19994e for type 'struct ip6_hdr', which requires 4 byte alignment 0x7efe1c19994e: note: pointer points here 02 fe 86 dd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x477817 in pinctrl_compose_ipv6 controller/pinctrl.c:4607 #1 0x47cbaa in ip_mcast_querier_send_mld controller/pinctrl.c:5445 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

UB Sanitizer report: controller/pinctrl.c:1921:54: runtime error: member access within misaligned address 0x00000261ce26 for type 'const struct sctp_init_chunk', which requires 4 byte alignment 0x00000261ce26: note: pointer points here 01 00 00 14 00 00 00 02 00 00 00 00 00 01 00 01 00 00 00 02 00 00 00 03 00 05 11 00 00 00 00 04 ^ #0 0x466da5 in pinctrl_handle_sctp_abort controller/pinctrl.c:1921 #1 0x46725a in pinctrl_handle_reject controller/pinctrl.c:1975 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

UB Sanitizer report: controller/pinctrl.c:2945:33: runtime error: load of misaligned address 0x000002ce5407 for type 'const ovs_be16', which requires 2 byte alignment 0x000002ce5407: note: pointer points here 6f 72 67 00 00 01 00 01 00 00 00 00 00 00 03 00 05 00 00 00 00 00 04 00 10 00 00 00 00 00 00 00 ^ #0 0x46d12d in pinctrl_handle_dns_lookup controller/pinctrl.c:2945 #1 0x46e6fa in process_packet_in controller/pinctrl.c:3186 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

UB Sanitizer report: controller/pinctrl.c:1700:21: runtime error: member access within misaligned address 0x7f8b1195e58e for type 'struct ip6_hdr', which requires 4 byte alignment 0x7f8b1195e58e: note: pointer points here 00 21 86 dd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x464f92 in pinctrl_handle_icmp controller/pinctrl.c:1700 #1 0x467344 in pinctrl_handle_reject controller/pinctrl.c:1967 #2 0x46e96e in process_packet_in controller/pinctrl.c:3217 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

UB Sanitizer report: lib/actions.c:1849:23: runtime error: member access within misaligned address 0x000002cefc83 for type 'struct controller_event_opt_header', which requires 2 byte alignment 0x000002cefc83: note: pointer points here 31 3a 38 30 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 57 30 2c 20 70 72 00 07 41 00 00 00 00 00 00 ^ #0 0x457034 in encode_event_empty_lb_backends_opts lib/actions.c:1849 #1 0x4573fa in encode_TRIGGER_EVENT lib/actions.c:1873 #2 0x46b95d in ovnact_encode lib/actions.c:4263 #3 0x46bb23 in ovnacts_encode lib/actions.c:4281 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

UB Sanitizer report: controller/pinctrl.c:6013:27: runtime error: member access within misaligned address 0x000002028836 for type 'struct ovs_ra_msg', which requires 4 byte alignment 0x000002028836: note: pointer points here 00 00 00 02 86 00 00 00 ff 00 ff ff 00 00 00 00 00 00 00 00 01 01 fa 16 3e 00 00 01 03 04 40 c0 ^ #0 0x47fb65 in pinctrl_handle_put_nd_ra_opts controller/pinctrl.c:6013 #1 0x46e0f1 in process_packet_in controller/pinctrl.c:3165 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

packet_set_ipv6() calls packet_rh_present() which expects L3 and L4 offsets to be set in the packet. If not, it may incorrectly iterate outside the bounds of the packet. We now call dp_packet_set_l4() before packet_set_ipv6() in pinctrl_compose_ipv6(). This also means that now packet_set_ipv6() will update the L4 checksums so we need to make sure we zero them out when recomputing them, e.g., in pinctrl_handle_tcp_reset(). Reported by AddressSanitizer: ==3919971==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fd9eecfc7b4 at pc 0x00000065d7a7 bp 0x7fd9eecfc580 sp 0x7fd9eecfc578 READ of size 1 at 0x7fd9eecfc7b4 thread T1 (ovn_pinctrl0) #0 0x65d7a6 in packet_rh_present lib/packets.c:1220 #1 0x65d7a6 in packet_set_ipv6 lib/packets.c:1339 #2 0x450eeb in pinctrl_compose_ipv6 controller/pinctrl.c:4577 #3 0x4540f3 in ip_mcast_querier_send_mld controller/pinctrl.c:5408 ovn-org#4 0x478de5 in ip_mcast_querier_send controller/pinctrl.c:5463 ovn-org#5 0x478de5 in ip_mcast_querier_run controller/pinctrl.c:5486 ovn-org#6 0x478de5 in pinctrl_handler controller/pinctrl.c:3400 ovn-org#7 0x62f183 in ovsthread_wrapper lib/ovs-thread.c:422 ovn-org#8 0x7fd9f26cd298 in start_thread /usr/src/debug/glibc-2.33-20.fc34.x86_64/nptl/pthread_create.c:481 ovn-org#9 0x7fd9f24a4352 in clone (/lib64/libc.so.6+0x100352) Address 0x7fd9eecfc7b4 is located in stack of thread T1 (ovn_pinctrl0) at offset 292 in frame #0 0x453eff in ip_mcast_querier_send_mld controller/pinctrl.c:5402 This frame has 6 object(s): [32, 48) 'unspecified' (line 5422) [64, 128) 'ofpacts' (line 5427) [160, 288) 'packet_stub' (line 5404) <== Memory access at offset 292 overflows this variable Fixes: 6e475f9 ("pinctrl: Ensure proper alignment when using pinctrl_compose_ipv*().") Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Numan Siddique <numans@ovn.org> (cherry picked from commit 6fa3409)

UB Sanitizer reports: controller/pinctrl.c:4607:17: runtime error: member access within misaligned address 0x7efe1c19994e for type 'struct ip6_hdr', which requires 4 byte alignment 0x7efe1c19994e: note: pointer points here 02 fe 86 dd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x477817 in pinctrl_compose_ipv6 controller/pinctrl.c:4607 #1 0x47cbaa in ip_mcast_querier_send_mld controller/pinctrl.c:5445 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

UB Sanitizer report: controller/pinctrl.c:1921:54: runtime error: member access within misaligned address 0x00000261ce26 for type 'const struct sctp_init_chunk', which requires 4 byte alignment 0x00000261ce26: note: pointer points here 01 00 00 14 00 00 00 02 00 00 00 00 00 01 00 01 00 00 00 02 00 00 00 03 00 05 11 00 00 00 00 04 ^ #0 0x466da5 in pinctrl_handle_sctp_abort controller/pinctrl.c:1921 #1 0x46725a in pinctrl_handle_reject controller/pinctrl.c:1975 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

UB Sanitizer report: controller/pinctrl.c:2945:33: runtime error: load of misaligned address 0x000002ce5407 for type 'const ovs_be16', which requires 2 byte alignment 0x000002ce5407: note: pointer points here 6f 72 67 00 00 01 00 01 00 00 00 00 00 00 03 00 05 00 00 00 00 00 04 00 10 00 00 00 00 00 00 00 ^ #0 0x46d12d in pinctrl_handle_dns_lookup controller/pinctrl.c:2945 #1 0x46e6fa in process_packet_in controller/pinctrl.c:3186 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

UB Sanitizer report: controller/pinctrl.c:1700:21: runtime error: member access within misaligned address 0x7f8b1195e58e for type 'struct ip6_hdr', which requires 4 byte alignment 0x7f8b1195e58e: note: pointer points here 00 21 86 dd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x464f92 in pinctrl_handle_icmp controller/pinctrl.c:1700 #1 0x467344 in pinctrl_handle_reject controller/pinctrl.c:1967 #2 0x46e96e in process_packet_in controller/pinctrl.c:3217 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

UB Sanitizer report: lib/actions.c:1849:23: runtime error: member access within misaligned address 0x000002cefc83 for type 'struct controller_event_opt_header', which requires 2 byte alignment 0x000002cefc83: note: pointer points here 31 3a 38 30 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 57 30 2c 20 70 72 00 07 41 00 00 00 00 00 00 ^ #0 0x457034 in encode_event_empty_lb_backends_opts lib/actions.c:1849 #1 0x4573fa in encode_TRIGGER_EVENT lib/actions.c:1873 #2 0x46b95d in ovnact_encode lib/actions.c:4263 #3 0x46bb23 in ovnacts_encode lib/actions.c:4281 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

UB Sanitizer report: controller/pinctrl.c:6013:27: runtime error: member access within misaligned address 0x000002028836 for type 'struct ovs_ra_msg', which requires 4 byte alignment 0x000002028836: note: pointer points here 00 00 00 02 86 00 00 00 ff 00 ff ff 00 00 00 00 00 00 00 00 01 01 fa 16 3e 00 00 01 03 04 40 c0 ^ #0 0x47fb65 in pinctrl_handle_put_nd_ra_opts controller/pinctrl.c:6013 #1 0x46e0f1 in process_packet_in controller/pinctrl.c:3165 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>

Reported by UB Sanitizer: lib/actions.c:2309:54: runtime error: applying zero offset to null pointer #0 0x4fa41b in free_gen_options /root/ovn/lib/actions.c:2309:54 #1 0x4d6f87 in ovnact_free /root/ovn/lib/actions.c:4297:9 #2 0x4d6f87 in ovnacts_free /root/ovn/lib/actions.c:4315:13 #3 0x4d67b6 in ovnacts_parse /root/ovn/lib/actions.c:4189:9 ovn-org#4 0x4d74a7 in ovnacts_parse_string /root/ovn/lib/actions.c:4208:5 ovn-org#5 0x49d3e7 in test_parse_actions /root/ovn/tests/test-ovn.c:1324:17 utilities/ovn-dbctl.c:467:16: runtime error: applying zero offset to null pointer #0 0x498a56 in has_option /root/ovn/utilities/ovn-dbctl.c:467:16 #1 0x497f91 in ovn_dbctl_main /root/ovn/utilities/ovn-dbctl.c:167:13 #2 0x4a0b46 in main /root/ovn/utilities/ovn-sbctl.c:1526:12 #3 0x7ff3cdd56b74 in __libc_start_main (/lib64/libc.so.6+0x27b74) ovn-org#4 0x47147d in _start (/root/ovn/utilities/ovn-sbctl+0x47147d) utilities/ovn-dbctl.c:1063:29: runtime error: applying zero offset to null pointer #0 0x4bf407 in server_cmd_run /root/ovn/utilities/ovn-dbctl.c:1063:29 #1 0x739bdc in process_command /root/ovs/lib/unixctl.c:310:13 #2 0x73853e in run_connection /root/ovs/lib/unixctl.c:344:17 #3 0x738228 in unixctl_server_run /root/ovs/lib/unixctl.c:395:21 ovn-org#4 0x4badf5 in server_loop /root/ovn/utilities/ovn-dbctl.c:1128:9 ovn-org#5 0x4badf5 in ovn_dbctl_main /root/ovn/utilities/ovn-dbctl.c:196:9 Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Numan Siddique <numans@ovn.org>

packet_set_ipv6() calls packet_rh_present() which expects L3 and L4 offsets to be set in the packet. If not, it may incorrectly iterate outside the bounds of the packet. We now call dp_packet_set_l4() before packet_set_ipv6() in pinctrl_compose_ipv6(). This also means that now packet_set_ipv6() will update the L4 checksums so we need to make sure we zero them out when recomputing them, e.g., in pinctrl_handle_tcp_reset(). Reported by AddressSanitizer: ==3919971==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fd9eecfc7b4 at pc 0x00000065d7a7 bp 0x7fd9eecfc580 sp 0x7fd9eecfc578 READ of size 1 at 0x7fd9eecfc7b4 thread T1 (ovn_pinctrl0) #0 0x65d7a6 in packet_rh_present lib/packets.c:1220 #1 0x65d7a6 in packet_set_ipv6 lib/packets.c:1339 #2 0x450eeb in pinctrl_compose_ipv6 controller/pinctrl.c:4577 #3 0x4540f3 in ip_mcast_querier_send_mld controller/pinctrl.c:5408 ovn-org#4 0x478de5 in ip_mcast_querier_send controller/pinctrl.c:5463 ovn-org#5 0x478de5 in ip_mcast_querier_run controller/pinctrl.c:5486 ovn-org#6 0x478de5 in pinctrl_handler controller/pinctrl.c:3400 ovn-org#7 0x62f183 in ovsthread_wrapper lib/ovs-thread.c:422 ovn-org#8 0x7fd9f26cd298 in start_thread /usr/src/debug/glibc-2.33-20.fc34.x86_64/nptl/pthread_create.c:481 ovn-org#9 0x7fd9f24a4352 in clone (/lib64/libc.so.6+0x100352) Address 0x7fd9eecfc7b4 is located in stack of thread T1 (ovn_pinctrl0) at offset 292 in frame #0 0x453eff in ip_mcast_querier_send_mld controller/pinctrl.c:5402 This frame has 6 object(s): [32, 48) 'unspecified' (line 5422) [64, 128) 'ofpacts' (line 5427) [160, 288) 'packet_stub' (line 5404) <== Memory access at offset 292 overflows this variable Fixes: 6e475f9 ("pinctrl: Ensure proper alignment when using pinctrl_compose_ipv*().") Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Numan Siddique <numans@ovn.org>

Fix it by using shash_destroy_free_data() instead of shash_destroy(). Example of asan log of this memory leak: Direct leak of 232 byte(s) in 29 object(s) allocated from: #0 0x534b0f in malloc (/home/hanzhou/src/ovn/_build_as/controller/ovn-controller+0x534b0f) #1 0x73bd4d in xmalloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:137:15 #2 0x73bd4d in xmalloc /home/hanzhou/src/ovs/_build/../lib/util.c:172:12 #3 0x638c49 in parse_constant_set /home/hanzhou/src/ovn/_build_as/../lib/expr.c:971:14 ovn-org#4 0x64450d in expr_parse_primary /home/hanzhou/src/ovn/_build_as/../lib/expr.c:1390:44 ovn-org#5 0x63aefc in expr_parse_not /home/hanzhou/src/ovn/_build_as/../lib/expr.c:1479:16 ovn-org#6 0x63ac45 in expr_parse__ /home/hanzhou/src/ovn/_build_as/../lib/expr.c:1486:22 ovn-org#7 0x63b500 in expr_parse /home/hanzhou/src/ovn/_build_as/../lib/expr.c:1535:34 ovn-org#8 0x63b500 in expr_parse_string /home/hanzhou/src/ovn/_build_as/../lib/expr.c:1557:25 ovn-org#9 0x598a56 in convert_match_to_expr /home/hanzhou/src/ovn/_build_as/../controller/lflow.c:1240:22 ovn-org#10 0x591c07 in consider_logical_flow__ /home/hanzhou/src/ovn/_build_as/../controller/lflow.c:1407:16 ovn-org#11 0x58d641 in add_logical_flows /home/hanzhou/src/ovn/_build_as/../controller/lflow.c:393:9 ovn-org#12 0x58d641 in lflow_run /home/hanzhou/src/ovn/_build_as/../controller/lflow.c:2444:5 ovn-org#13 0x5f57a3 in en_lflow_output_run /home/hanzhou/src/ovn/_build_as/../controller/ovn-controller.c:2449:5 ovn-org#14 0x65bc04 in engine_recompute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:380:5 ovn-org#15 0x65b2a3 in engine_run_node /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:456:17 ovn-org#16 0x65b2a3 in engine_run /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:493:9 ovn-org#17 0x5ef9c1 in main /home/hanzhou/src/ovn/_build_as/../controller/ovn-controller.c ovn-org#18 0x7f82418691a1 in __libc_start_main (/lib64/libc.so.6+0x281a1) Reported-by: Numan Siddique <numans@ovn.org> Fixes: aa3e4e8 ("lflow: Track reference count of address sets when parsing lflows.") Signed-off-by: Han Zhou <hzhou@ovn.org>

The asan log: Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0x534cb7 in calloc (/home/hanzhou/src/ovn/_build_as/controller/ovn-controller+0x534cb7) #1 0x73bf9e in xcalloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:121:31 #2 0x73bf9e in xzalloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:131:12 #3 0x73bf9e in xzalloc /home/hanzhou/src/ovs/_build/../lib/util.c:165:12 ovn-org#4 0x5f7629 in addr_sets_update /home/hanzhou/src/ovn/_build_as/../controller/ovn-controller.c:1484:21 ovn-org#5 0x5f7629 in addr_sets_sb_address_set_handler /home/hanzhou/src/ovn/_build_as/../controller/ovn-controller.c:1531:5 ovn-org#6 0x65b140 in engine_compute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:406:28 ovn-org#7 0x65b140 in engine_run_node /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:468:14 ovn-org#8 0x65b140 in engine_run /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:493:9 ovn-org#9 0x5ef9c1 in main /home/hanzhou/src/ovn/_build_as/../controller/ovn-controller.c ovn-org#10 0x7f3092dda1a1 in __libc_start_main (/lib64/libc.so.6+0x281a1) Reported-by: Numan Siddique <numans@ovn.org> Fixes: 6a60154 ("ovn-controller: Handle addresses deletion in address set incrementally.") Signed-off-by: Han Zhou <hzhou@ovn.org>

@pg1

Avoid the following crash in ovn-trace due to a reject action infinite loop: AddressSanitizer:DEADLYSIGNAL ==569410==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc0a991bc4 (pc 0x000000415081 bp 0x7ffc0a993fa0 sp 0x7ffc0a991b30 T0) #0 0x415081 in trace_actions utilities/ovn-trace.c:2617 #1 0x41d878 in trace_actions utilities/ovn-trace.c:2622 #2 0x41d878 in trace__ utilities/ovn-trace.c:3007 #3 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#4 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#5 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#6 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#7 0x41788d in execute_next utilities/ovn-trace.c:2307 ovn-org#8 0x41788d in trace_actions utilities/ovn-trace.c:2644 ovn-org#9 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622 ovn-org#10 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985 ovn-org#11 0x419671 in execute_reject utilities/ovn-trace.c:2049 ovn-org#12 0x419671 in trace_actions utilities/ovn-trace.c:2860 ovn-org#13 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#14 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#15 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#16 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#17 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#18 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#19 0x41788d in execute_next utilities/ovn-trace.c:2307 ovn-org#20 0x41788d in trace_actions utilities/ovn-trace.c:2644 ovn-org#21 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622 ovn-org#22 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985 ovn-org#23 0x419671 in execute_reject utilities/ovn-trace.c:2049 ovn-org#24 0x419671 in trace_actions utilities/ovn-trace.c:2860 ovn-org#25 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#26 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#27 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#28 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#29 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#30 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#31 0x41788d in execute_next utilities/ovn-trace.c:2307 ovn-org#32 0x41788d in trace_actions utilities/ovn-trace.c:2644 ovn-org#33 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622 ovn-org#34 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985 ovn-org#35 0x419671 in execute_reject utilities/ovn-trace.c:2049 ovn-org#36 0x419671 in trace_actions utilities/ovn-trace.c:2860 ovn-org#37 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#38 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#39 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#40 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#41 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#42 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#43 0x41788d in execute_next utilities/ovn-trace.c:2307 .... The issue can be triggered with the following reproducer: $ovn-nbctl ls-add sw $ovn-nbctl lsp-add sw p1 $ovn-nbctl lsp-set-addresses p1 "00:00:00:00:00:02 192.168.0.2" $ovn-nbctl lsp-add sw p2 $ovn-nbctl lsp-set-addresses p2 "00:00:00:00:00:03 192.168.0.3" $ovn-nbctl pg-add pg1 p1 p2 $ovn-nbctl acl-add pg1 to-lport 2003 "inport==@pg1 && ip4 && ip4.src == 192.168.0.0/16 && udp && udp.dst == 9000" allow $ovn-nbctl acl-add pg1 to-lport 2001 "inport==@pg1" reject $ovn-trace 'inport == "p2" && eth.src == 00:00:00:00:00:03 && eth.dst == 00:00:00:00:00:02 && ip.ttl==42 && ip4.src == 192.168.0.3' Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2074537 Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Mark Michelson <mmichels@redhat.com>

@pg1

Avoid the following crash in ovn-trace due to a reject action infinite loop: AddressSanitizer:DEADLYSIGNAL ==569410==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc0a991bc4 (pc 0x000000415081 bp 0x7ffc0a993fa0 sp 0x7ffc0a991b30 T0) #0 0x415081 in trace_actions utilities/ovn-trace.c:2617 #1 0x41d878 in trace_actions utilities/ovn-trace.c:2622 #2 0x41d878 in trace__ utilities/ovn-trace.c:3007 #3 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#4 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#5 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#6 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#7 0x41788d in execute_next utilities/ovn-trace.c:2307 ovn-org#8 0x41788d in trace_actions utilities/ovn-trace.c:2644 ovn-org#9 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622 ovn-org#10 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985 ovn-org#11 0x419671 in execute_reject utilities/ovn-trace.c:2049 ovn-org#12 0x419671 in trace_actions utilities/ovn-trace.c:2860 ovn-org#13 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#14 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#15 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#16 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#17 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#18 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#19 0x41788d in execute_next utilities/ovn-trace.c:2307 ovn-org#20 0x41788d in trace_actions utilities/ovn-trace.c:2644 ovn-org#21 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622 ovn-org#22 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985 ovn-org#23 0x419671 in execute_reject utilities/ovn-trace.c:2049 ovn-org#24 0x419671 in trace_actions utilities/ovn-trace.c:2860 ovn-org#25 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#26 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#27 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#28 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#29 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#30 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#31 0x41788d in execute_next utilities/ovn-trace.c:2307 ovn-org#32 0x41788d in trace_actions utilities/ovn-trace.c:2644 ovn-org#33 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622 ovn-org#34 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985 ovn-org#35 0x419671 in execute_reject utilities/ovn-trace.c:2049 ovn-org#36 0x419671 in trace_actions utilities/ovn-trace.c:2860 ovn-org#37 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#38 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#39 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#40 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#41 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#42 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#43 0x41788d in execute_next utilities/ovn-trace.c:2307 .... The issue can be triggered with the following reproducer: $ovn-nbctl ls-add sw $ovn-nbctl lsp-add sw p1 $ovn-nbctl lsp-set-addresses p1 "00:00:00:00:00:02 192.168.0.2" $ovn-nbctl lsp-add sw p2 $ovn-nbctl lsp-set-addresses p2 "00:00:00:00:00:03 192.168.0.3" $ovn-nbctl pg-add pg1 p1 p2 $ovn-nbctl acl-add pg1 to-lport 2003 "inport==@pg1 && ip4 && ip4.src == 192.168.0.0/16 && udp && udp.dst == 9000" allow $ovn-nbctl acl-add pg1 to-lport 2001 "inport==@pg1" reject $ovn-trace 'inport == "p2" && eth.src == 00:00:00:00:00:03 && eth.dst == 00:00:00:00:00:02 && ip.ttl==42 && ip4.src == 192.168.0.3' Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2074537 Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Mark Michelson <mmichels@redhat.com>

@pg1

Avoid the following crash in ovn-trace due to a reject action infinite loop: AddressSanitizer:DEADLYSIGNAL ==569410==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc0a991bc4 (pc 0x000000415081 bp 0x7ffc0a993fa0 sp 0x7ffc0a991b30 T0) #0 0x415081 in trace_actions utilities/ovn-trace.c:2617 #1 0x41d878 in trace_actions utilities/ovn-trace.c:2622 #2 0x41d878 in trace__ utilities/ovn-trace.c:3007 #3 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#4 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#5 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#6 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#7 0x41788d in execute_next utilities/ovn-trace.c:2307 ovn-org#8 0x41788d in trace_actions utilities/ovn-trace.c:2644 ovn-org#9 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622 ovn-org#10 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985 ovn-org#11 0x419671 in execute_reject utilities/ovn-trace.c:2049 ovn-org#12 0x419671 in trace_actions utilities/ovn-trace.c:2860 ovn-org#13 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#14 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#15 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#16 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#17 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#18 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#19 0x41788d in execute_next utilities/ovn-trace.c:2307 ovn-org#20 0x41788d in trace_actions utilities/ovn-trace.c:2644 ovn-org#21 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622 ovn-org#22 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985 ovn-org#23 0x419671 in execute_reject utilities/ovn-trace.c:2049 ovn-org#24 0x419671 in trace_actions utilities/ovn-trace.c:2860 ovn-org#25 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#26 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#27 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#28 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#29 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#30 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#31 0x41788d in execute_next utilities/ovn-trace.c:2307 ovn-org#32 0x41788d in trace_actions utilities/ovn-trace.c:2644 ovn-org#33 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622 ovn-org#34 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985 ovn-org#35 0x419671 in execute_reject utilities/ovn-trace.c:2049 ovn-org#36 0x419671 in trace_actions utilities/ovn-trace.c:2860 ovn-org#37 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#38 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#39 0x41e3a8 in execute_output utilities/ovn-trace.c:1700 ovn-org#40 0x416fcf in trace_actions utilities/ovn-trace.c:2640 ovn-org#41 0x41d878 in trace_actions utilities/ovn-trace.c:2622 ovn-org#42 0x41d878 in trace__ utilities/ovn-trace.c:3007 ovn-org#43 0x41788d in execute_next utilities/ovn-trace.c:2307 .... The issue can be triggered with the following reproducer: $ovn-nbctl ls-add sw $ovn-nbctl lsp-add sw p1 $ovn-nbctl lsp-set-addresses p1 "00:00:00:00:00:02 192.168.0.2" $ovn-nbctl lsp-add sw p2 $ovn-nbctl lsp-set-addresses p2 "00:00:00:00:00:03 192.168.0.3" $ovn-nbctl pg-add pg1 p1 p2 $ovn-nbctl acl-add pg1 to-lport 2003 "inport==@pg1 && ip4 && ip4.src == 192.168.0.0/16 && udp && udp.dst == 9000" allow $ovn-nbctl acl-add pg1 to-lport 2001 "inport==@pg1" reject $ovn-trace 'inport == "p2" && eth.src == 00:00:00:00:00:03 && eth.dst == 00:00:00:00:00:02 && ip.ttl==42 && ip4.src == 192.168.0.3' Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2074537 Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Mark Michelson <mmichels@redhat.com>

venkataanil reviewed Apr 14, 2020

View reviewed changes

numansiddique force-pushed the IP_FullIP/v3/p9 branch from 0d7b66c to 53f31c0 Compare April 14, 2020 14:30

numansiddique added 2 commits April 14, 2020 20:31

Refactor binding_run() to take two context argument - binding_ctx_in …

51df5a0

…and binding_ctx_out. No functional changes are introduced in this patch. Signed-off-by: Numan Siddique <numans@ovn.org>

numansiddique force-pushed the IP_FullIP/v3/p9 branch from 53f31c0 to 3bd6c0f Compare April 14, 2020 15:34

numansiddique and others added 7 commits April 15, 2020 14:00

numansiddique force-pushed the IP_FullIP/v3/p9 branch from 3bd6c0f to dbd65b4 Compare April 15, 2020 12:06

numansiddique force-pushed the master branch 6 times, most recently from 38a5351 to 5be9e1e Compare November 24, 2020 13:20

numansiddique force-pushed the master branch 4 times, most recently from 176890d to 031af9a Compare November 24, 2020 15:53

numansiddique force-pushed the master branch from 40efeb8 to 54513ad Compare March 11, 2021 11:26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ip full ip/v3/p9#1

Ip full ip/v3/p9#1
numansiddique wants to merge 9 commits into
mainfrom
IP_FullIP/v3/p9

numansiddique commented Apr 14, 2020

Uh oh!

venkataanil Apr 14, 2020

Uh oh!

numansiddique Apr 14, 2020

Uh oh!

venkataanil Apr 14, 2020

Uh oh!

numansiddique Apr 14, 2020

Uh oh!

venkataanil Apr 14, 2020

Uh oh!

venkataanil Apr 14, 2020

Uh oh!

numansiddique Apr 14, 2020

Uh oh!

venkataanil Apr 14, 2020

Uh oh!

numansiddique Apr 14, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

numansiddique commented Apr 14, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants