Ubuntu on IBM z Systems

  1. Bug #1896216
  2. Comment #5

Comment 5 for bug 1896216

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2020-09-21 05:55 EDT-------
SRU Justification:

[Impact]

* As zpci_dma_exit_device() is never called on a zPCI device that
is removed via PCI event which only informs Linxu of device removal
instead of requesting deconfiguration, the vmalloced memory for
DMA tables and vma tracking leaks in this case.

* This is because commit "s390/pci: adapt events for zbus" removed the zpci_disable_device() call for a zPCI event with PEC 0x0304 since
the device is then removed via zpci_release_device() however this
did not free the dma tables because the device already appeared
to be in Standby state.

[Fix]

* afdf9550e54627fcf4dd609bdc1153059378cdf5 afdf9550e546 "s390/pci: fix leak of DMA tables on hard unplug"

[Test Case]

* Have an IBM Z LPAR, that has PCIe devices (like RoCE adapters) assigned and Ubuntu Server 20.04 installed.

* Disable and re-enable one (or more) of the assigned PCIe cards using the Reassign I/O Path functionality of the HMC/SE,

* Monitor /proc/meminfo which shows the vmalloc memory usage not
go back to the value before attaching the device.

* The test and verification will be conducted by IBM.

[Regression Potential]

* There regression risk can be considered as moderate, because:

* Only a call of zpci_disable_device(zdev) got reintroduced (and some comment lines). This call was done in the same place and with the same
functionality prior to commit "s390/pci: adapt events for zbus".

* Since __zpci_event_availability gets modified, the zPCI event handling could be broken. It is however only modified for the single PEC 0x0304 case
and all cases execute independently.

* Nevertheless this could cause issues regarding the availability of zPCI devices

* In the worst case zPCI devices could become unusable.

* The code changes themselves are minimal, and the zPCI code is limited to the s390x architecture.

* On top test kernels were built and shared for further testing.

[Other]

* Since this commit needs to land in groovy too, but groovy is still in development (hence the SRU process does not apply for groovy yet, a separate Patch request for groovy was made.