[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1879704 Title: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1879704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
This bug was fixed in the package linux - 5.4.0-42.46 --- linux (5.4.0-42.46) focal; urgency=medium * focal/linux: 5.4.0-42.46 -proposed tracker (LP: #1887069) * linux 4.15.0-109-generic network DoS regression vs -108 (LP: #1886668) - SAUCE: Revert "netprio_cgroup: Fix unlimited memory leak of v2 cgroups" linux (5.4.0-41.45) focal; urgency=medium * focal/linux: 5.4.0-41.45 -proposed tracker (LP: #1885855) * Packaging resync (LP: #1786013) - update dkms package versions * CVE-2019-19642 - kernel/relay.c: handle alloc_percpu returning NULL in relay_open * CVE-2019-16089 - SAUCE: nbd_genl_status: null check for nla_nest_start * CVE-2020-11935 - aufs: do not call i_readcount_inc() * ip_defrag.sh in net from ubuntu_kernel_selftests failed with 5.0 / 5.3 / 5.4 kernel (LP: #1826848) - selftests: net: ip_defrag: ignore EPERM * Update lockdown patches (LP: #1884159) - SAUCE: acpi: disallow loading configfs acpi tables when locked down * seccomp_bpf fails on powerpc (LP: #1885757) - SAUCE: selftests/seccomp: fix ptrace tests on powerpc * Introduce the new NVIDIA 418-server and 440-server series, and update the current NVIDIA drivers (LP: #1881137) - [packaging] add signed modules for the 418-server and the 440-server flavours -- Khalid Elmously Thu, 09 Jul 2020 19:50:26 -0400 ** Changed in: linux (Ubuntu Groovy) Status: In Progress => Fix Released ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-16089 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-19642 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-11935 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1879704 Title: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1879704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
This bug was fixed in the package linux - 5.4.0-40.44 --- linux (5.4.0-40.44) focal; urgency=medium * linux-oem-5.6-tools-common and -tools-host should be dropped (LP: #1881120) - [Packaging] Add Conflicts/Replaces to remove linux-oem-5.6-tools-common and -tools-host * Packaging resync (LP: #1786013) - [Packaging] update helper scripts * Slow send speed with Intel I219-V on Ubuntu 18.04.1 (LP: #1802691) - e1000e: Disable TSO for buffer overrun workaround * CVE-2020-0543 - UBUNTU/SAUCE: x86/speculation/srbds: do not try to turn mitigation off when not supported * Realtek 8723DE [10ec:d723] subsystem [10ec:d738] disconnects unsolicitedly when Bluetooth is paired: Reason: 23=IEEE8021X_FAILED (LP: #1878147) - SAUCE: Revert "UBUNTU: SAUCE: rtw88: Move driver IQK to set channel before association for 11N chip" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: fix rate for a while after being connected" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: No retry and report for auth and assoc" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: 8723d: Add coex support" - rtw88: add a debugfs entry to dump coex's info - rtw88: add a debugfs entry to enable/disable coex mechanism - rtw88: 8723d: Add coex support - SAUCE: rtw88: coex: 8723d: set antanna control owner - SAUCE: rtw88: coex: 8723d: handle BT inquiry cases - SAUCE: rtw88: fix EAPOL 4-way failure by finish IQK earlier * CPU stress test fails with focal kernel (LP: #1867900) - [Config] Disable hisi_sec2 temporarily * Enforce all config annotations (LP: #1879327) - [Config]: do not enforce CONFIG_VERSION_SIGNATURE - [Config]: prepare to enforce all - [Config]: enforce all config options * Focal update: v5.4.44 upstream stable release (LP: #1881927) - ax25: fix setsockopt(SO_BINDTODEVICE) - dpaa_eth: fix usage as DSA master, try 3 - net: don't return invalid table id error when we fall back to PF_UNSPEC - net: dsa: mt7530: fix roaming from DSA user ports - net: ethernet: ti: cpsw: fix ASSERT_RTNL() warning during suspend - __netif_receive_skb_core: pass skb by reference - net: inet_csk: Fix so_reuseport bind-address cache in tb->fast* - net: ipip: fix wrong address family in init error path - net/mlx5: Add command entry handling completion - net: mvpp2: fix RX hashing for non-10G ports - net: nlmsg_cancel() if put fails for nhmsg - net: qrtr: Fix passing invalid reference to qrtr_local_enqueue() - net: revert "net: get rid of an signed integer overflow in ip_idents_reserve()" - net sched: fix reporting the first-time use timestamp - net/tls: fix race condition causing kernel panic - nexthop: Fix attribute checking for groups - r8152: support additional Microsoft Surface Ethernet Adapter variant - sctp: Don't add the shutdown timer if its already been added - sctp: Start shutdown on association restart if in SHUTDOWN-SENT state and socket is closed - tipc: block BH before using dst_cache - net/mlx5e: kTLS, Destroy key object after destroying the TIS - net/mlx5e: Fix inner tirs handling - net/mlx5: Fix memory leak in mlx5_events_init - net/mlx5e: Update netdev txq on completions during closure - net/mlx5: Fix error flow in case of function_setup failure - net/mlx5: Annotate mutex destroy for root ns - net/tls: fix encryption error checking - net/tls: free record only on encryption error - net: sun: fix missing release regions in cas_init_one(). - net/mlx4_core: fix a memory leak bug. - mlxsw: spectrum: Fix use-after-free of split/unsplit/type_set in case reload fails - ARM: dts: rockchip: fix phy nodename for rk3228-evb - ARM: dts: rockchip: fix phy nodename for rk3229-xms6 - arm64: dts: rockchip: fix status for in rk3328-evb.dts - arm64: dts: rockchip: swap interrupts interrupt-names rk3399 gpu node - ARM: dts: rockchip: swap clock-names of gpu nodes - ARM: dts: rockchip: fix pinctrl sub nodename for spi in rk322x.dtsi - gpio: tegra: mask GPIO IRQs during IRQ shutdown - ALSA: usb-audio: add mapping for ASRock TRX40 Creator - net: microchip: encx24j600: add missed kthread_stop - gfs2: move privileged user check to gfs2_quota_lock_check - gfs2: Grab glock reference sooner in gfs2_add_revoke - drm/amdgpu: drop unnecessary cancel_delayed_work_sync on PG ungate - drm/amd/powerplay: perform PG ungate prior to CG ungate - drm/amdgpu: Use GEM obj reference for KFD BOs - cachefiles: Fix race between read_waiter and read_copier involving op->to_do - usb: dwc3: pci: Enable extcon driver for Intel Merrifield - usb: phy: twl6030-usb: Fix a resource leak in an error handling path in 'twl6030_usb_probe()' - usb: gadget: legacy: fix redundant initialization warnings - net: freescale: select CONFIG_FIXED_PHY where needed - IB/i40iw: Remove bogus
[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
Many thanks for verifying. Adjusting tags. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1879704 Title: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1879704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1879704 Title: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1879704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1879704 Title: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1879704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
** Changed in: linux (Ubuntu Focal) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1879704 Title: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1879704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Groovy) Importance: High Assignee: Canonical Kernel Team (canonical-kernel-team) Status: In Progress ** Changed in: linux (Ubuntu Focal) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1879704 Title: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1879704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
For further assessment of potential regression, here is a reference to the upstream discussion with upstream maintainer Bjorn: https://lkml.org/lkml/2020/5/6/837 and especially his statement (https://lkml.org/lkml/2020/5/6/1252): >>This whole thing is not "introducing" any new functionality; it's >>"refactoring" to move existing functionality around and make it callable >>separately.<< -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1879704 Title: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1879704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
Kernel SRU request submitted: https://lists.ubuntu.com/archives/kernel-team/2020-June/thread.html#110753 Updating status to 'In Progress'. ** Changed in: linux (Ubuntu) Importance: Undecided => High ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: linux (Ubuntu) Status: Triaged => In Progress ** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1879704 Title: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1879704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
Many thx Niklas for the quick PPA testing!
** Description changed:
SRU Justification:
==
[Impact]
* It's currently not possible on s390x to verify the relationships
between PFs and VFs of network interfaces (neither natively nor in
libvirt).
* So s390x currently behaves differently here compared to other
architectures, but shouldn't, since this is needed for proper
management.
* The creation of not only the sysfs, but also the in-kernel link
(struct pci_dev->physfn), solves this and on top allows the use of a
common code path for disabling/shutdown of PFs.
* This code path is right now fenced off by the struct
pci_dev->no_vf_scan flag of which s390x is currently the only user.
* This allows to gracefully and orderly shutdown VFs associated with a
PF as triggered by '/sys/bus/pci/devices//sriov_numvfs'
* Previously this could leave the card in an unresponsive error state.
[Fix]
* a1ceea67f2e5b73cebd456e7fb463b3052bc6344 a1ceea67f2e5 "PCI/IOV:
Introduce pci_iov_sysfs_link() function"
* e5794cf1a270d813a5b9373a6876487d4d154195 e5794cf1a270 "s390/pci:
create links between PFs and VFs"
[Test Case]
* Setup an s390x LPAR with at least one SR-IOV card and assign PF and
VFs to that system.
* Determine if a device is a virtual function: for other architectures
this is currently available in the file 'physfn' which is a link to the
parent PF's device.
* Determine virtual functions of a physical function: for other
architectures this is currently available as 'virtfn{index}' links under
the PF device's directory.
* Determine the physical function of a virtual function: on x86 this is
currently available in the file 'physfn' which is a link to the parent
PF.
* This verification needs to be done by IBM on a system with SR-IOV
(PCI-based) hardware.
[Regression Potential]
* There is a certain regression risk with having code changes in the PCI/IOV
space,
- even is they are limited, especially is the patches touche common code.
+ even is they are limited, especially is the patches touche common code.
* The changes in pci.h are very minimal, and the iov.c changes are
traceable, too. All other modifications are s390x specific.
* Nevertheless, it could be that PCI hardware get harmed, here
especially (SR-)IOV hardware.
* The patches got cross-company verified (IBM and Google).
* They were brought upstream and are currently tagged with 20200521, and
are planned to be included in 5.8.
+ * A patched kernel was build in a LP PPA and already successfully tested
+ by IBM.
+
[Other]
* Since the fix/patch is planned to be included in kernel v5.8, it will
later automatically land in groovy.
* But because groovy is not there yet (5.8 is not yet out), this SRU got
requested for focal and groovy.
* This SRU depends on the SRU from LP 1874056, and this has already two ACKs.
- So LP 1874056 needs to be applied before this one!
+ So LP 1874056 needs to be applied before this one!
__
As with other architectures, we must be able on s390x to verify the
following relationships between PFs and VFs for proper management
(including by libvirt) of network interfaces:
1. Determine if a device is a virtual function: for other architectures this
is currently available in the file `physfn` which is a link to the parent PF's
device.
2. Determine virtual functions of a physical function: for other
architectures this is currently available as `virtfn{index}` links under the PF
device's directory.
3. Determine the physical function of a virtual function: on x86 this is
currently available in the file `physfn` which is a link to the parent PF
More details for the already existing parameters mentioned above can be
found here: https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-
bus-pci
Moreover creating not just the sysfs but also the in-kernel link
(struct pci_dev->physfn) also allows us to use the common code path
for disabling/shutdown of PFs.
This code path is currently fenced off by the
struct pci_dev->no_vf_scan flag of which s390 is currently the only user.
This in turn allows for a graceful and orderly shutdown of VFs
associated with a VF as triggered by:
echo 0 > /sys/bus/pci/devices//sriov_numvfs
Previously this could leave the card in an unresponsive error state.
The patches for this have been discussed and Acked-by the
responsible upstream maintainer here:
[RFC 0/2] Enable PF-VF linking with pdev->no_vf_scan (s390)
https://lore.kernel.org/linux-pci/20200506154139.90609-1-schne...@linux.ibm.com/
[RFC 1/2] PCI/IOV: Introduce pci_iov_sysfs_link() function
https://lore.kernel.org/linux-pci/20200506154139.90609-2-schne...@linux.ibm.com/
[RFC 2/2] s390/pci: create links between PFs and VFs
[Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
** Summary changed:
- [UBUNTU 20.04] s390x/pci: implement linking between PF and VF for
multifunction devices
+ [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction
devices
** Description changed:
SRU Justification:
==
[Impact]
* It's currently not possible on s390x to verify the relationships
between PFs and VFs of network interfaces (neither natively nor in
libvirt).
* So s390x currently behaves differently here compared to other
- architectures, but but shouldn't, since this is needed for proper
+ architectures, but shouldn't, since this is needed for proper
management.
- * On top the creation of not only the sysfs, but also the in-kernel link
- (struct pci_dev->physfn) allows the use of a common code path for
- disabling/shutdown of PFs.
+ * The creation of not only the sysfs, but also the in-kernel link
+ (struct pci_dev->physfn), solves this and on top allows the use of a
+ common code path for disabling/shutdown of PFs.
* This code path is right now fenced off by the struct
pci_dev->no_vf_scan flag of which s390x is currently the only user.
* This allows to gracefully and orderly shutdown VFs associated with a
PF as triggered by '/sys/bus/pci/devices//sriov_numvfs'
* Previously this could leave the card in an unresponsive error state.
[Fix]
* a1ceea67f2e5b73cebd456e7fb463b3052bc6344 a1ceea67f2e5 "PCI/IOV:
Introduce pci_iov_sysfs_link() function"
* e5794cf1a270d813a5b9373a6876487d4d154195 e5794cf1a270 "s390/pci:
create links between PFs and VFs"
[Test Case]
* Setup an s390x LPAR with at least one SR-IOV card and assign PF and
VFs to that system.
* Determine if a device is a virtual function: for other architectures
this is currently available in the file 'physfn' which is a link to the
parent PF's device.
* Determine virtual functions of a physical function: for other
architectures this is currently available as 'virtfn{index}' links under
the PF device's directory.
* Determine the physical function of a virtual function: on x86 this is
currently available in the file 'physfn' which is a link to the parent
PF.
* This verification needs to be done by IBM on a system with SR-IOV
(PCI-based) hardware.
[Regression Potential]
- * There is a certain regression risk with having code changes in the
- PCI/IOV space.
-
- * Especially because this (one of the two patches) touches common code.
+ * There is a certain regression risk with having code changes in the PCI/IOV
space,
+ even is they are limited, especially is the patches touche common code.
* The changes in pci.h are very minimal, and the iov.c changes are
- traceable, too. Everything else is s390x specific.
+ traceable, too. All other modifications are s390x specific.
* Nevertheless, it could be that PCI hardware get harmed, here
especially (SR-)IOV hardware.
* The patches got cross-company verified (IBM and Google).
* They were brought upstream and are currently tagged with 20200521, and
are planned to be included in 5.8.
[Other]
* Since the fix/patch is planned to be included in kernel v5.8, it will
later automatically land in groovy.
- * But because groovy is not there yet (5.8 is not yet out), this SRU
- request is for focal and groovy.
+ * But because groovy is not there yet (5.8 is not yet out), this SRU got
+ requested for focal and groovy.
- * This SRU depends on the SRU from LP 1874056, and this has already two ACKs.
So LP 1874056 needs to be applied before this one!
+ * This SRU depends on the SRU from LP 1874056, and this has already two ACKs.
+ So LP 1874056 needs to be applied before this one!
__
As with other architectures, we must be able on s390x to verify the
following relationships between PFs and VFs for proper management
(including by libvirt) of network interfaces:
1. Determine if a device is a virtual function: for other architectures this
is currently available in the file `physfn` which is a link to the parent PF's
device.
2. Determine virtual functions of a physical function: for other
architectures this is currently available as `virtfn{index}` links under the PF
device's directory.
3. Determine the physical function of a virtual function: on x86 this is
currently available in the file `physfn` which is a link to the parent PF
More details for the already existing parameters mentioned above can be
found here: https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-
bus-pci
Moreover creating not just the sysfs but also the in-kernel link
(struct pci_dev->physfn) also allows us to use the common code path
for disabling/shutdown of PFs.
This code path is currently fenced off by the
struct pci_dev->no_vf_scan flag of which s390 is currently the only user.
This in turn allows for a graceful and orderly shutdown of VFs
associated with a VF as triggered by:
