The FDP team is no longer accepting new bugs in Bugzilla. Please report your issues under FDP project in Jira. Thanks.
Bug 1991672 - [21.G RHEL-7] Fast Datapath Release
Summary: [21.G RHEL-7] Fast Datapath Release
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Fast Datapath
Classification: Red Hat
Component: openvswitch2.13
Version: FDP 21.G
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Timothy Redaelli
QA Contact: ovs-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-08-09 16:32 UTC by Timothy Redaelli
Modified: 2022-11-21 14:15 UTC (History)
4 users (show)

Fixed In Version: openvswitch2.13-2.13.0-102.el7fdp
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-21 14:15:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FD-1480 0 None None None 2021-08-09 16:34:42 UTC
Red Hat Product Errata RHBA-2022:8558 0 None None None 2022-11-21 14:15:50 UTC

Description Timothy Redaelli 2021-08-09 16:32:17 UTC
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>

Comment 3 Christian Trautman 2021-09-02 19:27:55 UTC
Ran regression,  no major blockers found

Comment 5 errata-xmlrpc 2022-11-21 14:15:48 UTC
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


Note You need to log in before you can comment on or make changes to this bug.