[Kernel-packages] [Bug 1935584] Re: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload
This bug was fixed in the package linux-bluefield - 5.4.0-1019.22 --- linux-bluefield (5.4.0-1019.22) focal; urgency=medium * focal/linux-bluefield: 5.4.0-1019.22 -proposed tracker (LP: #1942533) * Focal update: v5.4.134 upstream stable release (LP: #1939440) - [Config] bluefield: CONFIG_BATTERY_RT5033=m * Fix fragmentation support for TC connection tracking (LP: #1940872) - net/sched: act_ct: fix restore the qdisc_skb_cb after defrag - net/sched: act_ct: fix miss set mru for ovs after defrag in act_ct - net/sched: fix miss init the mru in qdisc_skb_cb - net/sched: act_ct: fix wild memory access when clearing fragments - Revert "net/sched: act_ct: Fix skb double-free in tcf_ct_handle_fragments() error flow" - net/sched: act_mirred: refactor the handle of xmit - net/sched: The error lable position is corrected in ct_init_module - net/sched: sch_frag: add generic packet fragment support. - ipv6: add ipv6_fragment hook in ipv6_stub * Add the upcoming BlueField-3 device ID (LP: #1941803) - net/mlx5: Update the list of the PCI supported devices * CT state not reset when packet redirected to different port (LP: #1940448) - Revert "UBUNTU: SAUCE: net/sched: act_mirred: Reset ct when reinserting skb back into queue" - net: sched: act_mirred: Reset ct info when mirror/redirect skb * Export xfrm_policy_lookup_bytype function (LP: #1934313) - SAUCE: xfrm: IPsec Export xfrm_policy_lookup_bytype function [ Ubuntu: 5.4.0-85.95 ] * focal/linux: 5.4.0-85.95 -proposed tracker (LP: #1942557) * please drop virtualbox-guest-dkms virtualbox-guest-source (LP: #1933248) - [Config] Disable virtualbox dkms build * Packaging resync (LP: #1786013) - debian/dkms-versions -- update from kernel-versions (main/2021.09.06) * LRMv5: switch primary version handling to kernel-versions data set (LP: #1928921) - [Packaging] switch to kernel-versions * disable “CONFIG_HISI_DMA” config for ubuntu version (LP: #1936771) - Disable CONFIG_HISI_DMA - [Config] Record hisi_dma no longer built for arm64 * memory leaking when removing a profile (LP: #1939915) - apparmor: Fix memory leak of profile proxy * CryptoExpress EP11 cards are going offline (LP: #1939618) - s390/zcrypt: Support for CCA protected key block version 2 - s390: Replace zero-length array with flexible-array member - s390/zcrypt: Use scnprintf() for avoiding potential buffer overflow - s390/zcrypt: replace snprintf/sprintf with scnprintf - s390/ap: Remove ap device suspend and resume callbacks - s390/zcrypt: use fallthrough; - s390/zcrypt: use kvmalloc instead of kmalloc for 256k alloc - s390/ap: remove power management code from ap bus and drivers - s390/ap: introduce new ap function ap_get_qdev() - s390/zcrypt: use kzalloc - s390/zcrypt: fix smatch warnings - s390/zcrypt: code beautification and struct field renames - s390/zcrypt: split ioctl function into smaller code units - s390/ap: rename and clarify ap state machine related stuff - s390/zcrypt: provide cex4 cca sysfs attributes for cex3 - s390/ap: rework crypto config info and default domain code - s390/zcrypt: simplify cca_findcard2 loop code - s390/zcrypt: remove set_fs() invocation in zcrypt device driver - s390/ap: remove unnecessary spin_lock_init() - s390/zcrypt: Support for CCA APKA master keys - s390/zcrypt: introduce msg tracking in zcrypt functions - s390/ap: split ap queue state machine state from device state - s390/ap: add error response code field for ap queue devices - s390/ap: add card/queue deconfig state - s390/sclp: Add support for SCLP AP adapter config/deconfig - s390/ap: Support AP card SCLP config and deconfig operations - s390/ap/zcrypt: revisit ap and zcrypt error handling - s390/zcrypt: move ap_msg param one level up the call chain - s390/zcrypt: Introduce Failure Injection feature - s390/zcrypt: fix wrong format specifications - s390/ap: fix ap devices reference counting - s390/zcrypt: return EIO when msg retry limit reached - s390/zcrypt: fix zcard and zqueue hot-unplug memleak - s390/ap: Fix hanging ioctl caused by wrong msg counter * memfd from ubuntu_kernel_selftests failed to build on B-5.4 (LP: #1926142) - SAUCE: selftests/memfd: fix build when F_SEAL_FUTURE_WRITE is not defined * [SRU] Ice driver causes the kernel to crash with Ubuntu 20.04.2 with ethtool specific register commands (LP: #1939855) - ice: Fix bad register reads * ubunut_kernel_selftests: memory-hotplug: avoid spamming logs with dump_page() (LP: #1941829) - selftests: memory-hotplug: avoid spamming logs with dump_page(), ratio limit hot-remove error test * e1000e blocks the boot process when it tried to write checksum to its NVM (LP: #1936998) - e1000e: Do not take care about recovery NVM checksum * Focal
[Kernel-packages] [Bug 1935584] Re: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1935584 Title: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug(s) When using ovs internal port with tc the redirect rules to internal port is back to ingress instead of egress. When we reinsert the skb we start from chain 0 but it could be ct state already set so matching rules on the internal port queue would miss. * brief explanation of fixes When reinserting skb back to ingress queue to restart tc classification then also reset ct. * How to test The setup was created by using ovn and testing iperf traffic from host container to VF pod. The result was ip set on the ovs bridge netdev (internal port) The rules were from rep to eventually the internal port and internal port to rep. The rules were with ct actions and chains tc-policy was set to skip-hw. Without the commit the traffic doesn’t work when hw-offload was true (offload to tc sw only) but does work with hw-offload false (ovs dp). * What it could break. Traffic not working in some cases using internal ports and CT. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1935584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1935584] Re: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- focal' to 'verification-done-focal'. If the problem still exists, change the tag 'verification-needed-focal' to 'verification-failed-focal'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-focal -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1935584 Title: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug(s) When using ovs internal port with tc the redirect rules to internal port is back to ingress instead of egress. When we reinsert the skb we start from chain 0 but it could be ct state already set so matching rules on the internal port queue would miss. * brief explanation of fixes When reinserting skb back to ingress queue to restart tc classification then also reset ct. * How to test The setup was created by using ovn and testing iperf traffic from host container to VF pod. The result was ip set on the ovs bridge netdev (internal port) The rules were from rep to eventually the internal port and internal port to rep. The rules were with ct actions and chains tc-policy was set to skip-hw. Without the commit the traffic doesn’t work when hw-offload was true (offload to tc sw only) but does work with hw-offload false (ovs dp). * What it could break. Traffic not working in some cases using internal ports and CT. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1935584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1935584] Re: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload
** Changed in: linux-bluefield (Ubuntu Focal) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1935584 Title: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug(s) When using ovs internal port with tc the redirect rules to internal port is back to ingress instead of egress. When we reinsert the skb we start from chain 0 but it could be ct state already set so matching rules on the internal port queue would miss. * brief explanation of fixes When reinserting skb back to ingress queue to restart tc classification then also reset ct. * How to test The setup was created by using ovn and testing iperf traffic from host container to VF pod. The result was ip set on the ovs bridge netdev (internal port) The rules were from rep to eventually the internal port and internal port to rep. The rules were with ct actions and chains tc-policy was set to skip-hw. Without the commit the traffic doesn’t work when hw-offload was true (offload to tc sw only) but does work with hw-offload false (ovs dp). * What it could break. Traffic not working in some cases using internal ports and CT. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1935584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1935584] Re: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload
** Changed in: linux-bluefield (Ubuntu) Status: In Progress => Invalid ** Changed in: linux-bluefield (Ubuntu) Assignee: Bodong Wang (bodong-wang) => (unassigned) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1935584 Title: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: In Progress Bug description: * Explain the bug(s) When using ovs internal port with tc the redirect rules to internal port is back to ingress instead of egress. When we reinsert the skb we start from chain 0 but it could be ct state already set so matching rules on the internal port queue would miss. * brief explanation of fixes When reinserting skb back to ingress queue to restart tc classification then also reset ct. * How to test The setup was created by using ovn and testing iperf traffic from host container to VF pod. The result was ip set on the ovs bridge netdev (internal port) The rules were from rep to eventually the internal port and internal port to rep. The rules were with ct actions and chains tc-policy was set to skip-hw. Without the commit the traffic doesn’t work when hw-offload was true (offload to tc sw only) but does work with hw-offload false (ovs dp). * What it could break. Traffic not working in some cases using internal ports and CT. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1935584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1935584] Re: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload
** Changed in: linux-bluefield (Ubuntu Focal) Importance: Undecided => Medium -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1935584 Title: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload Status in linux-bluefield package in Ubuntu: In Progress Status in linux-bluefield source package in Focal: In Progress Bug description: * Explain the bug(s) When using ovs internal port with tc the redirect rules to internal port is back to ingress instead of egress. When we reinsert the skb we start from chain 0 but it could be ct state already set so matching rules on the internal port queue would miss. * brief explanation of fixes When reinserting skb back to ingress queue to restart tc classification then also reset ct. * How to test The setup was created by using ovn and testing iperf traffic from host container to VF pod. The result was ip set on the ovs bridge netdev (internal port) The rules were from rep to eventually the internal port and internal port to rep. The rules were with ct actions and chains tc-policy was set to skip-hw. Without the commit the traffic doesn’t work when hw-offload was true (offload to tc sw only) but does work with hw-offload false (ovs dp). * What it could break. Traffic not working in some cases using internal ports and CT. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1935584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1935584] Re: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload
** Also affects: linux-bluefield (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux-bluefield (Ubuntu Focal) Status: New => In Progress ** Changed in: linux-bluefield (Ubuntu Focal) Assignee: (unassigned) => Bodong Wang (bodong-wang) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1935584 Title: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload Status in linux-bluefield package in Ubuntu: In Progress Status in linux-bluefield source package in Focal: In Progress Bug description: * Explain the bug(s) When using ovs internal port with tc the redirect rules to internal port is back to ingress instead of egress. When we reinsert the skb we start from chain 0 but it could be ct state already set so matching rules on the internal port queue would miss. * brief explanation of fixes When reinserting skb back to ingress queue to restart tc classification then also reset ct. * How to test The setup was created by using ovn and testing iperf traffic from host container to VF pod. The result was ip set on the ovs bridge netdev (internal port) The rules were from rep to eventually the internal port and internal port to rep. The rules were with ct actions and chains tc-policy was set to skip-hw. Without the commit the traffic doesn’t work when hw-offload was true (offload to tc sw only) but does work with hw-offload false (ovs dp). * What it could break. Traffic not working in some cases using internal ports and CT. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1935584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
