NAK: [SRU][F][G][PATCH 0/1] s390x/pci: do not allow to create more pci functions than configured via CONFIG_PCI_NR_FUNCTIONS (LP: 1874057)

Seth Forshee seth.forshee at canonical.com
Thu Apr 30 21:47:21 UTC 2020


On Mon, Apr 27, 2020 at 08:55:53PM +0200, frank.heimes at canonical.com wrote:
> Buglink: https://bugs.launchpad.net/bugs/1874057
> 
> SRU Justification:
> 
> [Impact]
> 
> * PCI Functions with UIDs >128 are currently not accounted correctly in the s390x/pci (zPCI) code.
> 
> * Furthermore, the code allows that more than CONFIG_PCI_NR_FUNCTIONS are created.
> 
> * This can lead to issues with data structures which were only allocated for CONFIG_PCI_NR_FUNCTIONS.
> 
> [Fix]
> 
> * https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874057/+attachment/5357850/+files/0001-s390-pci-Fix-zpci_alloc_domain-over-allocation-for-focal.patch
> 
> [Test Case]
> 
> * Set the kernel parameter CONFIG_PCI_NR_FUNCTIONS to a specific (reasonablly low) number.
> 
> * And check if more PCI functions can be created than specified by CONFIG_PCI_NR_FUNCTIONS (e.g. using a RoCE adapter) and watch for kernel message 'Adding PCI function ... failed'
> 
> 
> [Regression Potential] 
> 
> * There is regression potential can be considered as low, since:
> 
> * the zPCI cards are less wide spread than for example ccw adapters on s390x
> 
> * the fix got already upstream accepted in 5.7, hence upstream reviewed, too
> 
> * the modifications span just two files and both are s390x arch specific
> 
> [Other Info]
> 
> * the above patch-file is based on commit 969ae01bab2fe938b4c8324836038b5ac1c78fac ("s390/pci: Fix zpci_alloc_domain() over allocation"), but this backport was needed for getting this applied to focal master-next
> 
> * and this patch got upstream accepted with kernel v5.7-rc1, hence on the long term it should be in 'gorilla'

This patch is from 5.7-rc1, but it lacks the upstream provenance. Please
use 'git cherry-pick -x' to include this information.

This patch is not required for unstable, which is already based on
5.7-rc.

Thanks,
Seth



More information about the kernel-team mailing list