Patch request submitted for focal:
https://lists.ubuntu.com/archives/kernel-team/2020-September/thread.html#113609
changing status to 'In Progress' for focal.
** Changed in: linux (Ubuntu Focal)
Status: New => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1896216
Title:
[Ubuntu 20.10] zPCI DMA tables and bitmap leak on hard unplug (PCI
Event 0x0304)
Status in Ubuntu on IBM z Systems:
In Progress
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Focal:
In Progress
Status in linux source package in Groovy:
In Progress
Bug description:
SRU Justification:
==================
[Impact]
* Since zpci_dma_exit_device() is never called on a zPCI device there
is a potential leaking in DMA tables and bitmaps.
* This is because commit "s390/pci: adapt events for zbus" removed the
zpci_disable_device() call for a zPCI event with PEC 0x0304 (means on
hot unplug).
* It is only not called on hot unplug with event type PEC 0x0304 - this is
the one where Linux is informed the device is
gone instead of being asked to deconfigure it.
* It should also always leak them with that event type on an enabled
device.
[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 hotplug) - on LPAR this can be triggered using the 'Reassign
I/O Path' function at the HMC/SE.
* Monitor DMA tables and bitmaps for any kind of leaking.
* Since these tables are vmalloc-ed memory, it's sufficient to monitor
via /proc/meminfo and see that reassigning back and forth of a device
will have the memory usage grow continuously.
* The test and verification needs to 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).
* Since __zpci_event_availability gets modified, the zPCI event
handling could be scrud up,
* which could cause issues regarding the availability of zPCI devices
* and in worst case make zPCI devices unusable.
* But only one switch case of the function is modified and all cases
break, so only PEC 0x0304 should be affected.
* And 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),
I've sent a separate Patch request for groovy.
__________
Commit "s390/pci: adapt events for zbus" removed the
zpci_disable_device() call for a zPCI event with PEC 0x0304 (hot
unplug) because the device is already deconfigured by the platform.
This however skips the Linux side of the disable in particular it leads
to leaking the DMA tables and bitmaps because zpci_dma_exit_device() is
never called on the device.
This has been fixed in the following commit (currently in linux-next)
afdf9550e54627fcf4dd609bdc1153059378cdf5 s390/pci: fix leak of DMA
tables on hard unplug
The commit re-introduces the zpci_disable_device() call as it was before the
zbus introduction, for good measure I also added a comment to
zpci_disable_device()
to call out the fact that it may be called with the device disabled
already.
As the commit was introduced with the multi-function support
this of course should go into both 20.10 and 20.04.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1896216/+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
