summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* dpctl: Fix dereferencing null pointer in parse_ct_limit_zones().branch-3.1Zhiqi Chen2023-05-112-2/+19
| | | | | | | | | Command with empty string following "dpctl/ct-get-limits zone=" such as "ovs-appctl dpctl/ct-get-limits zone=" will cause parse_ct_limit_zones() dereferencing null. Signed-off-by: Zhiqi Chen <chenzhiqi.123@bytedance.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* netdev-offload: Fix deadlock/recursive use of the netdev_hmap_rwlock rwlock.Eelco Chaudron2023-05-101-32/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing performance testing with OVS v3.1 we ran into a deadlock situation with the netdev_hmap_rwlock read/write lock. After some debugging, it was discovered that the netdev_hmap_rwlock read lock was taken recursively. And well in the following sequence of events: netdev_ports_flow_get() It takes the read lock, while it walks all the ports in the port_to_netdev hmap and calls: - netdev_flow_get() which will call: - netdev_tc_flow_get() which will call: - netdev_ifindex_to_odp_port() This function also takes the same read lock to walk the ifindex_to_port hmap. In OVS a read/write lock does not support recursive readers. For details see the comments in ovs-thread.h. If you do this, it will lock up, mainly due to OVS setting the PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP attribute to the lock. The solution with this patch is to use two separate read/write locks, with an order guarantee to avoid another potential deadlock. Fixes: 9fe21a4fc12a ("netdev-offload: replace netdev_hmap_mutex to netdev_hmap_rwlock") Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2182541 Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto-dpif-xlate: Fix use-after-free when xlate_actions().Yunjian Wang2023-05-101-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, bundle->cvlans and xbundle->cvlans are pointing to the same memory location. This can cause issues if the main thread modifies bundle->cvlans and frees it while the revalidator thread is still accessing xbundle->cvlans. This leads to use-after-free error. AddressSanitizer: heap-use-after-free on address 0x615000007b08 at pc 0x0000004ede1e bp 0x7f3120ee0310 sp 0x7f3120ee0300 READ of size 8 at 0x615000007b08 thread T25 (revalidator25) 0 0x4ede1d in bitmap_is_set lib/bitmap.h:91 1 0x4fcb26 in xbundle_allows_cvlan ofproto/ofproto-dpif-xlate.c:2028 2 0x4fe279 in input_vid_is_valid ofproto/ofproto-dpif-xlate.c:2294 3 0x502abf in xlate_normal ofproto/ofproto-dpif-xlate.c:3051 4 0x5164dc in xlate_output_action ofproto/ofproto-dpif-xlate.c:5361 5 0x522576 in do_xlate_actions ofproto/ofproto-dpif-xlate.c:7047 6 0x52a751 in xlate_actions ofproto/ofproto-dpif-xlate.c:8061 7 0x4e2b66 in xlate_key ofproto/ofproto-dpif-upcall.c:2212 8 0x4e2e13 in xlate_ukey ofproto/ofproto-dpif-upcall.c:2227 9 0x4e345d in revalidate_ukey__ ofproto/ofproto-dpif-upcall.c:2276 10 0x4e3f85 in revalidate_ukey ofproto/ofproto-dpif-upcall.c:2395 11 0x4e7ac5 in revalidate ofproto/ofproto-dpif-upcall.c:2858 12 0x4d9ed3 in udpif_revalidator ofproto/ofproto-dpif-upcall.c:1010 13 0x7cd92e in ovsthread_wrapper lib/ovs-thread.c:423 14 0x7f312ff01f3a (/usr/lib64/libpthread.so.0+0x8f3a) 15 0x7f312fc8f51f in clone (/usr/lib64/libc.so.6+0xf851f) 0x615000007b08 is located 8 bytes inside of 512-byte region [0x615000007b00,0x615000007d00) freed by thread T0 here: 0 0x7f3130378ad8 in free (/usr/lib64/libasan.so.4+0xe0ad8) 1 0x49044e in bundle_set ofproto/ofproto-dpif.c:3431 2 0x444f92 in ofproto_bundle_register ofproto/ofproto.c:1455 3 0x40e6c9 in port_configure vswitchd/bridge.c:1300 4 0x40bcfd in bridge_reconfigure vswitchd/bridge.c:921 5 0x41f1a9 in bridge_run vswitchd/bridge.c:3313 6 0x42d4fb in main vswitchd/ovs-vswitchd.c:132 7 0x7f312fbbcc86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86) previously allocated by thread T0 here: 0 0x7f3130378e70 in __interceptor_malloc 1 0x8757fe in xmalloc__ lib/util.c:140 2 0x8758da in xmalloc lib/util.c:175 3 0x875927 in xmemdup lib/util.c:188 4 0x475f63 in bitmap_clone lib/bitmap.h:79 5 0x47797c in vlan_bitmap_clone lib/vlan-bitmap.h:40 6 0x49048d in bundle_set ofproto/ofproto-dpif.c:3433 7 0x444f92 in ofproto_bundle_register ofproto/ofproto.c:1455 8 0x40e6c9 in port_configure vswitchd/bridge.c:1300 9 0x40bcfd in bridge_reconfigure vswitchd/bridge.c:921 10 0x41f1a9 in bridge_run vswitchd/bridge.c:3313 11 0x42d4fb in main vswitchd/ovs-vswitchd.c:132 12 0x7f312fbbcc86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86) Fixes: fed8962aff57 ("Add new port VLAN mode "dot1q-tunnel"") Signed-off-by: Yunjian Wang <wangyunjian@huawei.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ci: Separate DPDK from OVS build.David Marchand2023-05-056-78/+145
| | | | | | | | | | | | | | Let's separate DPDK compilation from the rest of OVS build: - this avoids multiple jobs building DPDK in parallel, which especially affects builds in the dpdk-latest branch, - we separate concerns about DPDK build requirements from OVS build requirements, like python dependencies, - building DPDK does not depend on how we will link OVS against it, so we can use a single cache entry regardless of DPDK_SHARED option, Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David Marchand <david.marchand@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ovsdb-idl.at: Fix write-changed-only tests without change tracking.Ilya Maximets2023-05-041-2/+2
| | | | | | | | | | | | | | The '-w' command line argument is not passed to test-ovsdb in the OVSDB_CHECK_IDL_WRITE_CHANGED_ONLY_C, so it juts repeats normal tests without testing the feature. Adding the flag. And using the long version of the flag to make things more obvious and harder to overlook. Swapping the argument in the other working test as well, just for consistency. Fixes: d94cd0d3eec3 ("ovsdb-idl: Support write-only-changed IDL monitor mode.") Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* tc: Fix cleaning chains.Roi Dayan2023-04-282-4/+11
| | | | | | | | | | | | | Sometimes there is a need to clean empty chains as done in delete_chains_from_netdev(). The cited commit doesn't remove the chain completely which cause adding ingress_block later to fail. This can be reproduced with adding bond as ovs port which makes ovs use ingress_block for it. While at it add the netdev name that fails to the log. Fixes: e1e5eac5b016 ("tc: Add TCA_KIND flower to delete and get operation to avoid rtnl_lock().") Signed-off-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* python-stream: Handle SSL error in do_handshake.Stefan Hoffmann2023-04-261-1/+2
| | | | | | | | | | | | | | | | | | | In some cases ovsdb server or relay gets restarted, ovsdb python clients may keep the local socket open. Instead of reconnecting a lot of failures will be logged. This can be reproduced with ssl connections to the server/relay and restarting it, so it has the same IP after restart. This patch catches the Exceptions at do_handshake to recreate the connection on the client side. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Stefan Hoffmann <stefan.hoffmann@cloudandheat.com> Signed-off-by: Luca Czesla <luca.czesla@mail.schwarz> Signed-off-by: Max Lamprecht <max.lamprecht@mail.schwarz> Co-authored-by: Luca Czesla <luca.czesla@mail.schwarz> Co-authored-by: Max Lamprecht <max.lamprecht@mail.schwarz> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* dpif-netlink: Fix memory leak dpif_netlink_open().Yunjian Wang2023-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the specific call to dpif_netlink_dp_transact() (line 398) in dpif_netlink_open(), the 'dp' content is not being used in the branch when no error is returned (starting line 430). Furthermore, the 'dp' and 'buf' variables are overwritten later in this same branch when a new netlink request is sent (line 437), which results in a memory leak. Reported by Address Sanitizer. Indirect leak of 1024 byte(s) in 1 object(s) allocated from: 0 0x7fe09d3bfe70 in __interceptor_malloc (/usr/lib64/libasan.so.4+0xe0e70) 1 0x8759be in xmalloc__ lib/util.c:140 2 0x875a9a in xmalloc lib/util.c:175 3 0x7ba0d2 in ofpbuf_init lib/ofpbuf.c:141 4 0x7ba1d6 in ofpbuf_new lib/ofpbuf.c:169 5 0x9057f9 in nl_sock_transact lib/netlink-socket.c:1113 6 0x907a7e in nl_transact lib/netlink-socket.c:1817 7 0x8b5abe in dpif_netlink_dp_transact lib/dpif-netlink.c:5007 8 0x89a6b5 in dpif_netlink_open lib/dpif-netlink.c:398 9 0x5de16f in do_open lib/dpif.c:348 10 0x5de69a in dpif_open lib/dpif.c:393 11 0x5de71f in dpif_create_and_open lib/dpif.c:419 12 0x47b918 in open_dpif_backer ofproto/ofproto-dpif.c:764 13 0x483e4a in construct ofproto/ofproto-dpif.c:1658 14 0x441644 in ofproto_create ofproto/ofproto.c:556 15 0x40ba5a in bridge_reconfigure vswitchd/bridge.c:885 16 0x41f1a9 in bridge_run vswitchd/bridge.c:3313 17 0x42d4fb in main vswitchd/ovs-vswitchd.c:132 18 0x7fe09cc03c86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86) Fixes: b841e3cd4a28 ("dpif-netlink: Fix feature negotiation for older kernels.") Reviewed-by: David Marchand <david.marchand@redhat.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Yunjian Wang <wangyunjian@huawei.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofp-parse: Check ranges on string to uint32_t conversion.Yunjian Wang2023-04-251-5/+2
| | | | | | | | | | | An unnecessarily overflow would occurs when the 'value' is longer than 4294967295. So it's required to check ranges to avoid uint32_t overflow. Reported-by: Nan Zhou <zhounan14@huawei.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Yunjian Wang <wangyunjian@huawei.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* learning-switch: Fix coredump of OpenFlow15 learning-switch.Faicker Mo2023-04-254-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OpenFlow15 Packet-Out message contains the match instead of the in_port. The flow.tunnel.metadata.tab is not inited but used in the loop of tun_metadata_to_nx_match. The coredump gdb backtrace is: 0 memcpy_from_metadata (dst=0x2f060, src=0x30880, loc=0x10) at lib/tun-metadata.c:467 1 metadata_loc_from_match_read (match=0x30598, is_masked=<..>, mask=0x30838, idx=0, map=0x0) at lib/tun-metadata.c:865 2 metadata_loc_from_match_read (is_masked=<...>, mask=0x30838, idx=0, match=0x30598, map=0x0) at lib/tun-metadata.c:854 3 tun_metadata_to_nx_match (b=0x892260, oxm=OFP15_VERSION, match=0x30598) at lib/tun-metadata.c:888 4 nx_put_raw (b=0x892260, oxm=OFP15_VERSION, match=0x30598, cookie=<...>, cookie=0, cookie_mask=<...>, cookie_mask=0) at lib/nx-match.c:1186 5 oxm_put_match (b=0x892260, match=0x30598, version=OFP15_VERSION) at lib/nx-match.c:1343 6 ofputil_encode_packet_out (po=0x30580, protocol=<...>) at lib/ofp-packet.c:1226 7 process_packet_in (sw=0x891d70, oh=<...>) at lib/learning-switch.c:619 8 lswitch_process_packet (msg=0x892210, sw=0x891d70) at lib/learning-switch.c:374 9 lswitch_run (sw=0x891d70) at lib/learning-switch.c:324 10 main (argc=<...>, argv=<...>) at utilities/ovs-testcontroller.c:180 Fix that by initing the flow metadata. Fixes: 35eb6326d5d0 ("ofp-util: Add flow metadata to ofputil_packet_out") Signed-off-by: Faicker Mo <faicker.mo@ucloud.cn> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ovsdb: Allow conversion records with no data in a clustered storage.Ilya Maximets2023-04-244-36/+93
| | | | | | | | | | | | | | | | | | | | | | | | | If the schema with no data was read from the clustered storage, it should mean a database conversion request. In general, we can get: 1. Just data --> Transaction record. 2. Schema + Data --> Database conversion or raft snapshot install. 3. Just schema --> New. Database conversion request. We cannot distinguish between conversion and snapshot installation request in the current implementation, so we will keep handling conversion with data in the same way as before, i.e. if data is provided, we should use it. ovsdb-tool is updated to handle this record type as well while converting cluster to standalone. This change doesn't introduce a way for such records to appear in the database. That will be added in the future commits targeting conversion speed increase. Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ovsdb: Check for ephemeral columns before writing a new schema.Ilya Maximets2023-04-245-12/+24
| | | | | | | | | | | | | | | | | | Clustered databases do not support ephemeral columns, but ovsdb-server checks for them after the conversion result is read from the storage. It's much easier to recover if this constraint is checked before writing to the storage instead. It's not a big problem, because the check is always performed by the native ovsdb clients before sending a conversion request. But the server, in general, should not trust clients to do the right thing. Check in the update_schema() remains, because we shouldn't blindly trust the storage. Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ovsdb-tool: Fix cluster-to-standalone for DB conversion records.Ilya Maximets2023-04-244-0/+107
| | | | | | | | | | | | | | | | | | | If database conversion happens, both schema and the new data are present in the database record. However, the schema is just silently ignored by ovsdb-tool cluster-to-standalone. This creates data inconsistency if the new data contains new columns, for example, so the resulting database file will not be readable, or data will be lost. Fix that by re-setting the database whenever a conversion record is found and actually writing a new schema that will match the actual data. The database file will not be that similar to the original, but there is no way to represent conversion in a standalone database file format otherwise. Fixes: 00de46f9ee42 ("ovsdb-tool: Convert clustered db to standalone db.") Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ovs-tcpdump: Stdout is shutdown before ovs-tcpdump exit.Songtao Zhan2023-04-061-0/+11
| | | | | | | | | | | | If there is a pipe behind ovs-tcpdump (such as ovs-tcpdump -i eth0 | grep "192.168.1.1"), the child process (grep "192.168.1.1") may exit first and close the pipe when received SIGTERM. When farther process (ovs-tcpdump) exit, stdout is flushed into broken pipe, and then received a exception IOError. To avoid such problems, ovs-tcpdump first close stdout before exit. Signed-off-by: Songtao Zhan <zhanst1@chinatelecom.cn> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* Prepare for 3.1.2.Ilya Maximets2023-04-063-1/+10
| | | | | Acked-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* Set release date for 3.1.1.v3.1.1Ilya Maximets2023-04-062-2/+5
| | | | | Acked-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto-dpif-xlate: Always mask ip proto field.Aaron Conole2023-04-066-10/+229
| | | | | | | | | | | | | | | | | | | | | | | | | The ofproto layer currently treats nw_proto field as overloaded to mean both that a proper nw layer exists, as well as the value contained in the header for the nw proto. However, this is incorrect behavior as relevant standards permit that any value, including '0' should be treated as a valid value. Because of this overload, when the ofproto layer builds action list for a packet with nw_proto of 0, it won't build the complete action list that we expect to be built for the packet. That will cause a bad behavior where all packets passing the datapath will fall into an incomplete action set. The fix here is to unwildcard nw_proto, allowing us to preserve setting actions for protocols which we know have support for the actions we program. This means that a traffic which contains nw_proto == 0 cannot cause connectivity breakage with other traffic on the link. Reported-by: David Marchand <dmarchand@redhat.com> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2134873 Acked-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* conntrack-tp: Fix clang warning.Lin Huang2023-04-041-0/+7
| | | | | | | | | Declaration of 'struct conn' will not be visible outside of this function. Declaration of 'struct conntrack' will not be visible outside of this function. Declaration of 'struct timeout_policy' will not be visible outside of this function. Signed-off-by: Lin Huang <linhuang@ruijie.com.cn> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* netdev-offload-tc: Del ufid mapping if device not exist.Faicker Mo2023-04-032-1/+57
| | | | | | | | | | | | | | | | | The device may be deleted and added with ifindex changed. The tc rules on the device will be deleted if the device is deleted. The func tc_del_filter will fail when flow del. The mapping of ufid to tc will not be deleted. The traffic will trigger the same flow(with same ufid) to put to tc on the new device. Duplicated ufid mapping will be added. If the hashmap is expanded, the old mapping entry will be the first entry, and now the dp flow can't be deleted. Signed-off-by: Faicker Mo <faicker.mo@ucloud.cn> Acked-by: Eelco Chaudron <echaudro@redhat.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Tested-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* db-ctl-base: Partially revert b8bf410a5.Daniel Alvarez Sanchez2023-03-302-38/+12
| | | | | | | | | | | | | | | | | The commit b8bf410a5 [0] broke the `ovs-vsctl add` command which now overwrites the value if it existed already. This patch reverts the code around the `cmd_add` function to restore the previous behavior. It also adds testing coverage for this functionality. [0] https://github.com/openvswitch/ovs/commit/b8bf410a5c94173da02279b369d75875c4035959 Fixes: b8bf410a5c94 ("db-ctl-base: Use partial map/set updates for last add/set commands.") Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2182767 Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Daniel Alvarez Sanchez <dalvarez@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* netdev-tc-offloads: Fix misaligned 8 byte read.Mike Pattrick2023-03-291-2/+2
| | | | | | | | | | | | | | | | | | UB Sanitizer report: lib/netdev-offload-tc.c:1276:19: runtime error: load of misaligned address 0x7f74e801976c for type 'union ovs_u128', which requires 8 byte alignment 0 in netdev_tc_flow_dump_next lib/netdev-offload-tc.c:1276 1 in netdev_flow_dump_next lib/netdev-offload.c:303 2 in dpif_netlink_flow_dump_next lib/dpif-netlink.c:1921 [...] Fixes: 8f7620e6a406 ("netdev-tc-offloads: Implement netdev flow dump api using tc interface") Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ovs-thread: Fix cpus not read for the first 10s.Adrian Moreno2023-03-271-1/+1
| | | | | | | | | | | | | | | With the current implementation the available CPUs will not be read until 10s have passed since the system's boot. For systems that boot faster, this can make ovs-vswitchd create fewer handlers than necessary for some time. Fixes: 0d23948a598a ("ovs-thread: Detect changes in number of CPUs.") Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2180460 Suggested-by: Ilya Maximets <i.maximets@ovn.org> Acked-by: Mike Pattrick <mkp@redhat.com> Acked-by: Michael Santana <msantana@redhat.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* dpif-netlink: Always create at least 1 handler.Adrian Moreno2023-03-271-1/+1
| | | | | | | | | | | | Ensure at least 1 handler is created even if something goes wrong during cpu detection or prime numer calculation. Fixes: a5cacea5f988 ("handlers: Create additional handler threads when using CPU isolation.") Suggested-by: Aaron Conole <aconole@redhat.com> Acked-by: Mike Pattrick <mkp@redhat.com> Acked-by: Michael Santana <msantana@redhat.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* netdev-offload-tc: Fix parse_tc_flower_to_actions() reporting errors.Eelco Chaudron2023-03-221-9/+27
| | | | | | | | | parse_tc_flower_to_actions() was not reporting errors, which would cause parse_tc_flower_to_match() to ignore them. Fixes: dd03672f7bbb ("netdev-offload-tc: Move flower_to_match action handling to isolated function.") Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* vswitch: Add missing documentation for "ct_flush" capability.Ales Musil2023-03-151-0/+6
| | | | | | | Fixes: 08146bf7d9b4 ("openflow: Add extension to flush CT by generic match.") Signed-off-by: Ales Musil <amusil@redhat.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* dpctl: Fix flush-conntrack with datapath as argument.Ales Musil2023-03-153-3/+55
| | | | | | | | | | | | | | | | | | Specifying datapath with "dpctl/flush-conntrack" didn't work as expected and caused error: ovs-dpctl: field system@ovs-system missing value (Invalid argument) To prevent that, check if we have datapath as first argument and use it accordingly. Also add couple of test cases to ensure that everything works as expected. Fixes: a9ae73b916ba ("ofp, dpif: Allow CT flush based on partial match.") Signed-off-by: Ales Musil <amusil@redhat.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto-dpif-upcall: Wait for valid hw flow stats before applying ↵Eelco Chaudron2023-03-156-10/+48
| | | | | | | | | | | | | | | | | min-revalidate-pps. Depending on the driver implementation, it can take from 0.2 seconds up to 2 seconds before offloaded flow statistics are updated. This is true for both TC and rte_flow-based offloading. This is causing a problem with min-revalidate-pps, as old statistic values are used during this period. This fix will wait for at least 2 seconds, by default, before assuming no packets where received during this period. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* system-traffic: Fix conntrack test cases which are failing with af_xdp.Eelco Chaudron2023-03-131-2/+2
| | | | | | | | | | | | | | | | | | | The recently added test cases below are not passing on the af_xdp datapath due to tcpdump not working on the OVS ports with this datapath. conntrack - ICMP related NAT with single port conntrack - ICMPv6 related NAT with single port conntrack - ICMP from different source related with NAT The tests are changed to attach tcpdump on the associated veth port in the netns. Tests are now passing with all datapaths (afxdp, kernel, userspace, and offloads). Fixes: 8bd688063078 ("system-traffic.at: Add icmp error tests while dnatting address and port.") Fixes: 0a7587034dc9 ("conntrack: Properly unNAT inner header of related traffic.") Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Ales Musil <amusil@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* netdev-windows: Add checking when creating netdev with system type on WindowsWilson Peng2023-03-061-0/+11
| | | | | | | | | | | | | | | | | | | | In the recent Antrea project testing, some port could not be created on Windows. When doing debug, our team found there is one case happening when multiple ports are waiting for be created with correct port number. Some system type port will be created netdev successfully and it will cause conflict as in the dpif side it will be internal type. So finally the port will be created failed and it could not be easily recovered. With the patch, on Windows the netdev creating will be blocked for system type when the ovs_tyep got on dpif is internal. More detailed case description is in the reported issue No.262 with link below. Reported-at:https://github.com/openvswitch/ovs-issues/issues/262 Signed-off-by: Wilson Peng <pweisong@vmware.com> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* ofproto-dpif-upcall: Include hardware offloaded flows in total flows.Eelco Chaudron2023-03-031-0/+11
| | | | | | | | | | | | | | | | The revalidator process uses the internal call udpif_get_n_flows() to get the total number of flows installed in the system. It uses this value for various decisions on flow installation and removal. With the tc offload this values is incorrect, as the hardware offloaded are not included. With rte_flow offload this is not a problem as dpif netdev keeps both in sync. This patch will include the hardware offloaded flows if the underlying dpif implementation is not syncing them. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto-dpif-upcall: Reset ukey's last stats value if the datapath changed.Eelco Chaudron2023-03-037-2/+116
| | | | | | | | | | | | | When the ukey's action set changes, it could cause the flow to use a different datapath, for example, when it moves from tc to kernel. This will cause the the cached previous datapath statistics to be used. This change will reset the cached statistics when a change in datapath is discovered. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* classifier: Fix missing masks on a final stage with ports trie.Ilya Maximets2023-02-282-5/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Flow lookup doesn't include masks of the final stage in a resulting flow wildcards in case that stage had L4 ports match. Only the result of ports trie lookup is added to the mask. It might be sufficient in many cases, but it's not correct, because ports trie is not how we decided that the packet didn't match in this subtable. In fact, we used a full subtable mask in order to determine that, so all the subtable mask bits has to be added. Ports trie can still be used to adjust ports' mask, but it is not sufficient to determine that the packet didn't match. Assuming we have following 2 OpenFlow rules on the bridge: table=0, priority=10,tcp,tp_dst=80,tcp_flags=+psh actions=drop table=0, priority=0 actions=output(1) The first high priority rule supposed to drop all the TCP data traffic sent on port 80. The handshake, however, is allowed for forwarding. Both 'tcp_flags' and 'tp_dst' are on the final stage in the flow. Since the stage mask from that stage is not incorporated into the flow wildcards and only ports mask is getting updated, we have the following megaflow for the SYN packet that has no match on 'tcp_flags': $ ovs-appctl ofproto/trace br0 "in_port=br0,tcp,tp_dst=80,tcp_flags=syn" Megaflow: recirc_id=0,eth,tcp,in_port=LOCAL,nw_frag=no,tp_dst=80 Datapath actions: 1 If this flow is getting installed into datapath flow table, all the packets for port 80, regardless of TCP flags, will be forwarded. Incorporating all the looked at bits from the final stage into the stages map in order to get all the necessary wildcards. Ports mask has to be updated as a last step, because it doesn't cover the full 64-bit slot in the flowmap. With this change, in the example above, OVS is producing correct flow wildcards including match on TCP flags: Megaflow: recirc_id=0,eth,tcp,in_port=LOCAL,nw_frag=no,tp_dst=80,tcp_flags=-psh Datapath actions: 1 This way only -psh packets will be forwarded, as expected. This issue affects all other fields on stage 4, not only TCP flags. Tests included to cover tcp_flags, nd_target and ct_tp_src/dst. First two are frequently used, ct ones are sharing the same flowmap slot with L4 ports, so important to test. Before the pre-computation of stage masks, flow wildcards were updated during lookup, so there was no issue. The bits of the final stage was lost with introduction of 'stages_map'. Recent adjustment of segment boundaries exposed 'tcp_flags' to the issue. Reported-at: https://github.com/openvswitch/ovs-issues/issues/272 Fixes: ca44218515f0 ("classifier: Adjust segment boundary to execute prerequisite processing.") Fixes: fa2fdbf8d0c1 ("classifier: Pre-compute stage masks.") Acked-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto: Fix re-creation of tunnel backing interfaces on restart.Ilya Maximets2023-02-272-19/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tunnel OpenFlow ports do not exist in the datapath, instead there is a tunnel backing interface that serves all the tunnels of the same type. For example, if the geneve port 'my_tunnel' is added to OVS, it will create 'geneve_sys_6041' datapath port, if it doesn't already exist, and use this port as a tunnel output. However, while creating/opening a new datapath after re-start, ovs-vswitchd only has a list of names of OpenFlow interfaces. And it thinks that each datapath port, that is not on the list, is a stale port that needs to be removed. This is obviously not correct for tunnel backing interfaces that can serve multiple tunnel ports and do not match OpenFlow port names. This is causing removal and re-creation of all the tunnel backing interfaces in the datapath on OVS restart, causing disruption in existing connections. It's hard to tell by only having a name of the interface if this interface is a tunnel backing interface, or someone just named a normal interface this way. So, instead of trying to determine that, not removing any interfaces at all, while we don't know types of actual ports we need. Assuming that all the ports that are currently not in the list of OF ports are tunnel backing ports. Later, revalidation of tunnel backing ports in type_run() will determine which ports are still needed and which should be removed. It's OK to add even a non-tunnel stale ports into tnl_backers, they will be cleaned up the same way as stale tunnel backers. Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2023-February/052215.html Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* conntrack: Fix conntrack_clean may access the same exp_list each time.Liang Mancang2023-02-211-2/+2
| | | | | | | | | | | | | when a exp_list contains more than the clean_end's number of nodes, and these nodes will not expire immediately. Then, every times we call conntrack_clean, it use the same next_sweep to get exp_list. Actually, we should add i every times after we call ct_sweep. Fixes: 3d9c1b855a5f ("conntrack: Replace timeout based expiration lists with rculists.") Acked-by: Paolo Valerio <pvalerio@redhat.com> Signed-off-by: Liang Mancang <liangmc1@chinatelecom.cn> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ovs-actions: Correct typo in ovs-actions man page.Mike Pattrick2023-02-211-1/+1
| | | | | | | There was a minor typo in the ovs-actions man page. Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto-ipfix: Use per-domain template timeouts.Adrian Moreno2023-02-211-24/+105
| | | | | | | | | | | | | | | | | IPFIX templates have to be sent for each Observation Domain ID. Currently, a timer is kept at each dpif_ipfix_exporter to send them. This works fine for per-bridge sampling where there is only one Observation Domain ID per exporter. However, this is does not work for per-flow sampling where more than one Observation Domain IDs can be specified by the controller. In this case, ovs-vswitchd will only send template information for one (arbitrary) DomainID. Fix per-flow sampling by using an hmap to keep a timer for each Observation Domain ID. Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* Prepare for 3.1.1.Ilya Maximets2023-02-163-1/+10
| | | | | Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* Set release date for 3.1.0.v3.1.0Ilya Maximets2023-02-162-2/+2
| | | | | Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto-dpif-upcall: Use last known stats ukey stats on revalidate missed dp ↵Eelco Chaudron2023-02-151-1/+1
| | | | | | | | | | | | | | | flows. Instead of using all zero stats when executing a revalidate for missed dp flows, use the last known stats to avoid odd statistics being used. As these zero stats are stored in the ukey, the next time revalidate_ukey() is called the delta between the new stats and the zero stats is used, which would cause an additional increase in total packets/bytes. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Michael Santana <msantana@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* conntrack: Properly unNAT inner header of related traffic.Ales Musil2023-02-142-163/+196
| | | | | | | | | | | The inner header was not handled properly. Simplify the code which allows proper handling of the inner headers. Reported-at: https://bugzilla.redhat.com/2137754 Acked-by: Paolo Valerio <pvalerio@redhat.com> Signed-off-by: Ales Musil <amusil@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* sparse: Fix build with DPDK and GCC 12.David Marchand2023-02-101-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rte_vect.h pulls some AVX512 instrinsics headers added in GCC 12 [1] trigger a lot of warnings: libtool: compile: env "REAL_CC=ccache gcc" "CHECK=sparse -Wsparse-error -I ../include/sparse -I ../include -m64 -I /usr/local/include " cgcc -target=x86_64 -target=host_os_specs -D__MMX__=1 -D__MMX_WITH_SSE__=1 -D__SSE2_MATH__=1 -D__SSE_MATH__=1 -D__SSE__=1 -D__SSE2__=1 -DHAVE_CONFIG_H -I. -I.. -I ../include -I ./include -I ../lib -I ./lib -Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-arith -Wformat -Wformat-security -Wswitch-enum -Wunused-parameter -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -fno-strict-aliasing -Wswitch-bool -Wlogical-not-parentheses -Wsizeof-array-argument -Wbool-compare -Wshift-negative-value -Wduplicated-cond -Wshadow -Wmultistatement-macros -Wcast-align=strict -mssse3 -I/home/dmarchan/git/pub/dpdk.org/22.11/install/include -include rte_config.h -I/usr/local/include -Werror -D_FILE_OFFSET_BITS=64 -g -O2 -MT lib/bfd.lo -MD -MP -MF lib/.deps/bfd.Tpo -c ../lib/bfd.c -o lib/bfd.o ../lib/bfd.c: note: in included file (through /usr/lib/gcc/x86_64-redhat-linux/12//include/immintrin.h, /usr/lib/gcc/x86_64-redhat-linux/12//include/x86intrin.h, ...): /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:38:9: error: '_Float16' has implicit type /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:38:18: error: Expected ; at end of declaration /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:38:18: error: got __v8hf /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:62:41: error: Expected ; at end of statement /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:62:41: error: got { /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:420:32: error: Expected ) in expression /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:420:32: error: got __A /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:2271:61: error: Expected ) in function call /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:2271:61: error: got __A /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:2279:61: error: Expected ) in function call /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:2279:61: error: got __A /usr/lib/gcc/x86_64-redhat-linux/12//include/avx512fp16intrin.h:2328:50: error: Expected ) in function call [...] Besides, the list of headers by rte_memcpy.h is now out of sync with DPDK. OVS takes care to include the right headers in its sources. Simply make this header self-sufficient. 1: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a68412117fa4 Signed-off-by: David Marchand <david.marchand@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ovsdb-server: Fix handling of DNS name for listener configuration.Frode Nordahl2023-02-103-20/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 08e9e5337383 fixed proper initialization of the dns-resolve module, and made DNS resolution asynchronous. A side effect of that change revealed a long standing logic bug which broke ovsdb-server listener configuration using DNS names. Previously this worked because the DNS resolution would block, now that DNS resolution is asynchronous the code before this change would assume the error from jsonrpc_pstream_open meant the remote was a specification for an active outgoing connection, even when that was not the case. To fix this a couple of changes was made to socket-util: 1) Pass optional result of dns resolution from inet_parse_passive. When (re-)configuring listeners that use DNS names, we may need to know whether the provided connection string is invalid or if the provided DNS name has finished resolving. 2) Check dns resolution status in inet_open_passive. If the connection string is valid, and contains a DNS name, inet_open_passive will now return -EAGAIN if dns resolution failed. DNS resolution failure may either mean the asynchronous resolver has not completed yet, or that the name does not resolve. Reported-at: https://bugs.launchpad.net/bugs/1998781 Fixes: 08e9e5337383 ("ovsdb: raft: Fix inability to read the database with DNS host names.") Fixes: 771680d96fb6 ("DNS: Add basic support for asynchronous DNS resolving") Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* netdev-offload-tc: If the flow has not been used, report it as such.Eelco Chaudron2023-02-091-1/+13
| | | | | | | | | | | | | | | If a tc flow was installed but has not yet been used, report it as such. In addition, add a delay to the "IGMP - flood under normal action" test case to make it work with many repetitions. This delay is also present in other ICMP/IGMP tests. Fixes: f98e418fbdb6 ("tc: Add tc flower functions") Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Tested-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* netdev-offload-tc: Conntrack ALGs are not supported with tc.Eelco Chaudron2023-02-092-0/+15
| | | | | | | | | | | | | | | tc does not support conntrack ALGs. Even worse, with tc enabled, they should not be used/configured at all. This is because even though TC will ignore the rules with ALG configured, i.e., they will flow through the kernel module, return traffic might flow through a tc conntrack rule, and it will not invoke the ALG helper. Fixes: 576126a931cd ("netdev-offload-tc: Add conntrack support") Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Tested-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* netdev-offload-tc: Fix tc conntrack force commit support.Eelco Chaudron2023-02-091-2/+11
| | | | | | | | | | | | tc was not setting the OVS_CT_ATTR_FORCE_COMMIT flag when a forced commit was requested. This patch will fix this. Fixes: 576126a931cd ("netdev-offload-tc: Add conntrack support") Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Tested-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto-dpif-upcall: New ukey needs to take the old ukey's dump seq.Peng He2023-02-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The userspace datapath manages all the magaflows by a cmap. The cmap data structure will grow/shrink during the datapath processing and it will re-position megaflows. This might result in two revalidator threads might process a same megaflow during one dump stage. Consider a situation that, revalidator 1 processes a megaflow A, and decides to delete it from the datapath, at the mean time, this megaflow A is also queued in the process batch of revalidator 2. Normally it's ok for revalidators to process the same megaflow multiple times, as the dump_seq shows it's already dumped and the stats will not be contributed twice. Assume that right after A is deleted, a PMD thread generates again a new megaflow B which has the same match and action of A. The ukey of megaflow B will replace the one of megaflow A. Now the ukey B is new to the revalidator system and its dump seq is 0. Now since the dump seq of ukey B is 0, when processing megaflow A, the revalidator 2 will not identify this megaflow A has already been dumped by revalidator 1 and will contribute the old megaflow A's stats again, this results in an inconsistent stats between ukeys and megaflows. To fix this, the newly generated the ukey B should take the dump_seq of the replaced ukey A to avoid a same megaflow being revalidated twice in one dump stage. We observe in the production environment, the OpenFlow rules' stats sometimes are amplified compared to the actual value. Signed-off-by: Peng He <hepeng.0320@bytedance.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* netdev-offload-tc: Preserve tc statistics when flow gets modified.Eelco Chaudron2023-02-034-23/+218
| | | | | | | | | | | | | | | When a flow gets modified, i.e. the actions are changes, the tc layer will remove, and re-add the flow. This is causing all the counters to be reset. This patch will remember the previous tc counters and adjust any requests for statistics. This is done in a similar way as the rte_flow implementation. It also updates the check_pkt_len tc test to purge the flows, so we do not use existing updated tc flow counters, but start with fresh installed set of datapath flows. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* sparse: Fix numa.h for libnuma >= 2.0.13.Ilya Maximets2023-02-031-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Current numa.h header for sparse re-defines functions in a way that breaks the header from libnuma 2.0.13+, because the original issue was fixed in that version: https://github.com/numactl/numactl/commit/25dcde021dd4f1a1dcac2ba0094f1cb441a2e4a5 Sparse errors as a result: lib/netdev-afxdp.c: note: in included file (through include/sparse/numa.h): /usr/include/numa.h:346:26: error: macro "numa_get_interleave_mask_compat" passed 1 arguments, but takes just 0 /usr/include/numa.h:376:26: error: macro "numa_get_membind_compat" passed 1 arguments, but takes just 0 /usr/include/numa.h:406:26: error: macro "numa_get_run_node_mask_compat" passed 1 arguments, but takes just 0 /usr/include/numa.h:347:1: error: Expected ; at end of declaration /usr/include/numa.h:347:1: error: got { /usr/include/numa.h:351:9: error: 'tp' has implicit type It's hard to adjust defines to work with both versions of a header. Just defining all the functions we actually use in OVS instead and not including the original header. Fixes: e8568993e062 ("netdev-afxdp: NUMA-aware memory allocation for XSK related memory.") Reviewed-by: David Marchand <david.marchand@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* tc: Add TCA_KIND flower to delete and get operation to avoid rtnl_lock().Eelco Chaudron2023-01-304-13/+22
| | | | | | | | | | | | | | | | | | | | A long long time ago, an effort was made to make tc flower rtnl_lock() free. However, on the OVS part we forgot to add the TCA_KIND "flower" attribute, which tell the kernel to skip the lock. This patch corrects this by adding the attribute for the delete and get operations. The kernel code calls tcf_proto_is_unlocked() to determine the rtnl_lock() is needed for the specific tc protocol. It does this in the tc_new_tfilter(), tc_del_tfilter(), and in tc_get_tfilter(). If the name is not set, tcf_proto_is_unlocked() will always return false. If set, the specific protocol is queried for unlocked support. Fixes: f98e418fbdb6 ("tc: Add tc flower functions") Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* netdev-offload-tc: Fix misaligned access to ct label.Ilya Maximets2023-01-271-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UndefinedBehaviorSanitizer: lib/netdev-offload-tc.c:1356:50: runtime error: member access within misaligned address 0x60700001a89c for type 'const struct (unnamed struct at lib/netdev-offload-tc.c:1350:27)', which requires 8 byte alignment 0x60700001a89c: note: pointer points here 24 00 04 00 01 00 00 05 00 00 0d 00 0a 00 00 00 00 00 00 00 ... ^ 0 0xd5d183 in parse_put_flow_ct_action lib/netdev-offload-tc.c:1356:50 1 0xd5783f in netdev_tc_parse_nl_actions lib/netdev-offload-tc.c:2015:19 2 0xd4027c in netdev_tc_flow_put lib/netdev-offload-tc.c:2355:11 3 0x9666d7 in netdev_flow_put lib/netdev-offload.c:318:14 4 0xcd4c0a in parse_flow_put lib/dpif-netlink.c:2297:11 5 0xcd4c0a in try_send_to_netdev lib/dpif-netlink.c:2384:15 6 0xcd4c0a in dpif_netlink_operate lib/dpif-netlink.c:2455:23 7 0x87d40e in dpif_operate lib/dpif.c:1372:13 8 0x6d43e9 in handle_upcalls ofproto/ofproto-dpif-upcall.c:1674:5 9 0x6d43e9 in recv_upcalls ofproto/ofproto-dpif-upcall.c:905:9 10 0x6cf6ea in udpif_upcall_handler ofproto/ofproto-dpif-upcall.c:801:13 11 0xb6d7ea in ovsthread_wrapper lib/ovs-thread.c:423:12 12 0x7f5ccf017801 in start_thread 13 0x7f5ccefb744f in __GI___clone3 Fixes: 9221c721bec0 ("netdev-offload-tc: Add conntrack label and mark support") Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
View Lorry Controller Status