commit f7e3b47e09af7aa77c922fdb70ff0bb39551671b Author: Eli Britstein <elibr> Date: Mon Jul 26 11:14:54 2021 +0300 dpif-netdev: Fix offloads of modified flows. Association of a mark to a flow is done as part of its offload handling, in the offloading thread. However, the PMD thread specifies whether an offload request is an "add" or "modify" by the association of a mark to the flow. This is exposed to a race condition. A flow might be created with actions that cannot be fully offloaded, for example flooding (before MAC learning), and later modified to have actions that can be fully offloaded. If the two requests are queued before the offload thread handling, they are both marked as "add". When the offload thread handles them, the first request is partially offloaded, and the second one is ignored as the flow is already considered as offloaded. Fix it by specifying add/modify of an offload request by the actual flow state change, without relying on the mark. Fixes: 3c7330ebf036 ("netdev-offload-dpdk: Support offload of output action.") Signed-off-by: Eli Britstein <elibr> Reviewed-by: Gaetan Rivet <gaetanr> Signed-off-by: Ilya Maximets <i.maximets> commit 350507b1633ee8fa50f42bcd7f26881cf995cb2e Author: Eli Britstein <elibr> Date: Mon Jul 26 11:14:53 2021 +0300 dpif-netdev: Fix flow modification after failure. dp_netdev_flow_offload_main thread is asynchronous, by the cited commit. There might be a case where there are modification requests of the same flow submitted before handled. Then, if the first handling fails, the rule for the flow is deleted, and the mark is freed. Then, the following one should not be handled as a modification, but rather as an "add". Fixes: 02bb2824e51d ("dpif-netdev: do hw flow offload in a thread") Signed-off-by: Eli Britstein <elibr> Signed-off-by: Ilya Maximets <i.maximets> commit f92ce92e53eb2e559f2e7aae08b4a51386d22d32 Author: Ilya Maximets <i.maximets> Date: Fri Jul 23 15:41:20 2021 +0200 daemon-unix: Fix leak of a fork error message. 19 bytes in 1 blocks are definitely lost in loss record 24 of 121 at 0x4839748: malloc (vg_replace_malloc.c:306) by 0x483BD63: realloc (vg_replace_malloc.c:834) by 0x521C26: xrealloc (util.c:149) by 0x478F91: ds_reserve (dynamic-string.c:63) by 0x47928B: ds_put_format_valist (dynamic-string.c:161) by 0x47920A: ds_put_format (dynamic-string.c:142) by 0x506DE5: process_status_msg (process.c:0) by 0x52A6D0: fork_and_wait_for_startup (daemon-unix.c:284) by 0x52A54D: daemonize_start (daemon-unix.c:453) by 0x40EB3E: main (ovs-vswitchd.c:91) Fixes: b925336a36e6 ("daemon: restart child process if it died before signaling its readiness") Signed-off-by: Ilya Maximets <i.maximets> Acked-by: Roi Dayan <roid> commit d794934d019481d62942248e2c17cadc496079ed Author: Wilson Peng <pweisong> Date: Tue Jul 20 00:23:57 2021 -0700 datapath-windows:Correct checksum for DNAT action While testing OVS-windows flows for the DNAT action, the checksum In TCP header is set incorrectly when TCP offload is enabled by Default. As a result, the packet will be dropped on receiver linuxVM. >>>sample flow default configuration on both Windows VM and Linux VM (src=40.0.1.2,dst=10.150.0.1) --dnat--> (src=40.0.1.2,dst==30.1.0.2) Without the fix for some TCP packet(40.0.1.2->30.1.0.2 with payload len 207) the TCP checksum will be pseduo header checksum and the value is 0x01d6. With the fix the checksum will be 0x47ee, it could be got the correct TCP checksum on the receiver Linux VM. Signed-off-by: Wilson Peng<pweisong> Signed-off-by: Anand Kumar<kumaranand> Acked-by: Alin-Gabriel Serdean <aserdean> Signed-off-by: Alin-Gabriel Serdean <aserdean> commit 9b1c0df6ad13773b43592c51a0e19a988aca747c Author: Mark Gray <mark.d.gray> Date: Fri Jul 16 06:17:35 2021 -0400 dpif-netlink: Fix report_loss() message. Fixes: 1579cf677fcb ("dpif-linux: Implement the API functions to allow multiple handler threads read upcall.") Signed-off-by: Mark Gray <mark.d.gray> Acked-by: Flavio Leitner <fbl> Acked-by: Aaron Conole <aconole> Signed-off-by: Ilya Maximets <i.maximets> commit 17e98772cba38da159f6f3a2c8d8ae4010fd4ada Author: Eelco Chaudron <echaudro> Date: Fri Jul 16 14:04:50 2021 +0200 conntrack: Document all-zero IP SNAT behavior and add a test case. Currently, conntrack in the kernel has an undocumented feature referred to as all-zero IP address SNAT. Basically, when a source port collision is detected during the commit, the source port will be translated to an ephemeral port. If there is no collision, no SNAT is performed. This patchset documents this behavior and adds a self-test to verify it's not changing. In addition, a datapath feature flag is added for the all-zero IP SNAT case. This will help applications on top of OVS, like OVN, to determine this feature can be used. Signed-off-by: Eelco Chaudron <echaudro> Acked-by: Aaron Conole <aconole> Acked-by: Dumitru Ceara <dceara> Acked-by: Alin-Gabriel Serdean <aserdean> Acked-by: Paolo Valerio <pvalerio> Signed-off-by: Ilya Maximets <i.maximets> commit 305b944a2edcd74a7ff97acdb4ce00f05f5a1d80 Author: Dumitru Ceara <dceara> Date: Wed Jul 14 09:21:19 2021 +0200 ovsdb-server: Fix memleak when failing to read storage. Fixes: 1b1d2e6daa56 ("ovsdb: Introduce experimental support for clustered databases.") Signed-off-by: Dumitru Ceara <dceara> Signed-off-by: Ben Pfaff <blp> commit 1aa1f591422ec3e34ae9becf257081645500de6c Author: Eelco Chaudron <echaudro> Date: Mon Jul 5 07:57:41 2021 -0400 netdev-linux: Ignore TSO packets when TSO is not enabled for userspace. When TSO is disabled from a userspace forwarding datapath perspective, but TSO has been wrongly enabled on the kernel side, log a warning message, and drop the packet. With the current implementation, OVS will crash. [i.maximets]: The call stack looks like this: 0 dp_packet_set_size (b=0x0, b=0x0, v=13028) at lib/dp-packet.h:578 1 netdev_linux_batch_rxq_recv_sock at lib/netdev-linux.c:1310 2 netdev_linux_rxq_recv at lib/netdev-linux.c 3 netdev_rxq_recv at lib/netdev.c 4 dp_netdev_process_rxq_port at lib/dpif-netdev.c The problem is that the code assumes that (mmsgs[i].msg_len > std_len) can only be true if userpace-tso is enabled and additional buffers are provided to the kernel. However, since recvmmsg() is called with MSG_TRUNC, the resulting msg_len reflects the original packet size before truncation, and it can be larger than the buffer if TSO / GRO is enabled on the network interface. If TSO support for user space is not enabled in OVS, the aux_bufs are not allocated and are left NULL, resulting in a crash. Fixes: 73858f9dbe83 ("netdev-linux: Prepend the std packet in the TSO packet") Fixes: 2109841b7984 ("Use batch process recv for tap and raw socket in netdev datapath") Signed-off-by: Eelco Chaudron <echaudro> Acked-by: Flavio Leitner <fbl> Signed-off-by: Ilya Maximets <i.maximets> commit d127fa6d2bd7b5679cafab1f92b1237f374664bc Author: Paolo Valerio <pvalerio> Date: Tue Jul 6 15:03:05 2021 +0200 conntrack: Handle already natted packets. When a packet gets dnatted and then recirculated, it could be possible that it matches another rule that performs another nat action. The kernel datapath handles this situation turning to a no-op the second nat action, so natting only once the packet. In the userspace datapath instead, when the ct action gets executed, an initial lookup of the translated packet fails to retrieve the connection related to the packet, leading to the creation of a new entry in ct for the src nat action with a subsequent failure of the connection establishment. with the following flows: table=0,priority=30,in_port=1,ip,nw_dst=192.168.2.100,actions=ct(commit,nat(dst=10.1.1.2:80),table=1) table=0,priority=20,in_port=2,ip,actions=ct(nat,table=1) table=0,priority=10,ip,actions=resubmit(,2) table=0,priority=10,arp,actions=NORMAL table=0,priority=0,actions=drop table=1,priority=5,ip,actions=ct(commit,nat(src=10.1.1.240),table=2) table=2,in_port=ovs-l0,actions=2 table=2,in_port=ovs-r0,actions=1 Establishing a connection from 10.1.1.1 to 192.168.2.100 the outcome is: tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=4000,dport=80), reply=(src=10.1.1.2,dst=10.1.1.240,sport=80,dport=4000), protoinfo=(state=ESTABLISHED) tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=4000,dport=80), reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=4000), protoinfo=(state=ESTABLISHED) With this patch applied the outcome is: tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=4000,dport=80), reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=4000), protoinfo=(state=ESTABLISHED) The patch performs, for already natted packets, a lookup of the reverse key in order to retrieve the related entry, it also adds a test case that besides testing the scenario ensures that the other ct actions are executed. Reported-by: Dumitru Ceara <dceara> Signed-off-by: Paolo Valerio <pvalerio> Acked-by: Dumitru Ceara <dceara> Signed-off-by: Ilya Maximets <i.maximets> commit c8ebe4434cc88fcac8a4ec93bfbaad550a8b7a1b Author: Bodo Petermann <b.petermann> Date: Wed Jun 16 12:32:14 2021 +0200 python: Fix Idl.run change_seqno update. Fix an issue where Idl.run() returned False even if there was a change. If Idl.run() reads multiple messages from the database server, some may constitute changes and some may not. Changed the way change_seqno is reset: if a message is not a change, reset change_seqno only to the value before reading this message, not to the value before reading the first message. This will fix the return value in a scenario where some message was a change and the last one wasn't. The new change_seqno will now be the value after handling the message with the last change. Fixes: c39751e44539 ("python: Monitor Database table to manage lifecycle of IDL client.") Signed-off-by: Bodo Petermann <b.petermann> Acked-by: Alin Gabriel Serdean <aserdean> Signed-off-by: Ilya Maximets <i.maximets> commit 2762bf6895097c6ea84b60fe86ceb0edda1774b5 Author: Ilya Maximets <i.maximets> Date: Thu Jul 1 20:19:23 2021 +0200 Prepare for 2.13.5. Acked-by: Aaron Conole <aconole> Signed-off-by: Ilya Maximets <i.maximets> commit d72ccdfbda83a27abe7fd4d71a8df25b1543117a Author: Ilya Maximets <i.maximets> Date: Thu Jul 1 20:19:23 2021 +0200 Set release date for 2.13.4. Acked-by: Aaron Conole <aconole> Signed-off-by: Ilya Maximets <i.maximets> commit 76fdda2b34333ef799b01b2745288e49f01c171a Author: Toms Atteka <cpp.code.lv> Date: Mon Jun 7 11:31:39 2021 -0700 netlink: removed incorrect optimization This optimization caused FLOW_TNL_F_UDPIF flag not to be used in hash calculation for geneve tunnel when revalidating flows which resulted in different cache hash values and incorrect behaviour. Added test to prevent regression. CC: Jesse Gross <jesse> Fixes: 6728d578f64e ("dpif-netdev: Translate Geneve options per-flow, not per-packet.") Reported-at: https://github.com/vmware-tanzu/antrea/issues/897 Signed-off-by: Toms Atteka <cpp.code.lv> Acked-by: Ansis Atteka <aatteka> Signed-off-by: Ilya Maximets <i.maximets> commit 9c386761f99844505055544f46c6513c41737996 Author: Paolo Valerio <pvalerio> Date: Wed May 26 00:26:00 2021 +0200 ovs-actions.xml: Add missing bracket. A bracket is apparently missing in ovs-actions(7). The patch changes the relevant row from: ct(argument]...) to: ct([argument]...) Signed-off-by: Paolo Valerio <pvalerio> Signed-off-by: Ilya Maximets <i.maximets> commit be8c4af1cef11f5ef1d61c94ffc9dd8a387f3132 Author: Paolo Valerio <pvalerio> Date: Wed Apr 7 13:43:06 2021 +0200 netdev-offload-tc: Use nl_msg_put_flag for OVS_TUNNEL_KEY_ATTR_CSUM. When a tunnel port gets added to the bridge setting the checksum option to true: ovs-vsctl add-port br0 geneve0 \ -- set interface geneve0 type=geneve \ options:remote_ip=<remote_ip> options:key=<key> options:csum=true the flow dump for the outgoing traffic will include a "bad key length 1 ..." message: ovs-appctl dpctl/dump-flows --names -m ufid:<>, ..., dp:tc, actions:set(tunnel(tun_id=<>,dst=<>,ttl=64,tp_dst=6081, key6(bad key length 1, expected 0)(01)flags(key))) ,genev_sys_6081 This is due to a mismatch present between the expected length (zero for OVS_TUNNEL_KEY_ATTR_CSUM in ovs_tun_key_attr_lens) and the current one. With this patch the same flow dump becomes: ovs-appctl dpctl/dump-flows --names -m ufid:<>, ..., dp:tc, actions:set(tunnel(tun_id=<>,dst=<>,ttl=64,tp_dst=6081, flags(csum|key))),genev_sys_6081 Fixes: d9677a1f0eaf ("netdev-tc-offloads: TC csum option is not matched with tunnel configuration") Suggested-by: Ilya Maximets <i.maximets> Signed-off-by: Paolo Valerio <pvalerio> Acked-by: Eelco Chaudron <echaudro> Signed-off-by: Ilya Maximets <i.maximets>
Ran regression, no major blockers found
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (openvswitch2.13 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:8558