Commit "s390/pci: adapt events for zbus" removed the zpci_disable_device() call for a zPCI event with PEC 0x0304 (hot unplug) becausethe 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.
Commit "s390/pci: adapt events for zbus" removed the zpci_disable_ device( ) call for a zPCI event with PEC 0x0304 (hot unplug) becausethe device is already deconfigured by the platform.
This however skips the Linux side of the disable in particular it leads exit_device( ) is
to leaking the DMA tables and bitmaps because zpci_dma_
never called on the device.
This has been fixed in the following commit (currently in linux-next)
afdf9550e54627f cf4dd609bdc1153 059378cdf5 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.