s390/pci: fix leak of DMA tables on hard unplug
authorNiklas Schnelle <schnelle@linux.ibm.com>
Thu, 3 Sep 2020 11:42:57 +0000 (13:42 +0200)
committerVasily Gorbik <gor@linux.ibm.com>
Mon, 14 Sep 2020 08:08:07 +0000 (10:08 +0200)
commitafdf9550e54627fcf4dd609bdc1153059378cdf5
treeb958e58ec35514562fbc6b78977a54c7075ef85a
parentfcb2b70cdb194157678fb1a75f9ff499aeba3d2a
s390/pci: fix leak of DMA tables on hard unplug

commit f606b3ef47c9 ("s390/pci: adapt events for zbus") removed the
zpci_disable_device() call for a zPCI event with PEC 0x0304 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.

If the device transitions to the Reserved state we call zpci_zdev_put()
but zpci_release_device() will not call zpci_disable_device() because
the state of the zPCI function is already ZPCI_FN_STATE_STANDBY.

If the device is put into the Standby state, zpci_disable_device() is
not called and the device is assumed to have been put in Standby through
platform action.
At this point the device may be removed by a subsequent event with PEC
0x0308 or 0x0306 which calls zpci_zdev_put() with the same problem
as above or the device may be configured again in which case
zpci_disable_device() is also not called.

Fix this by calling zpci_disable_device() explicitly for PEC 0x0304 as
before. To make it more clear that zpci_disable_device() may be called,
even if the lower level device has already been disabled by the
platform, add a comment to zpci_disable_device().

Cc: <stable@vger.kernel.org> # 5.8
Fixes: f606b3ef47c9 ("s390/pci: adapt events for zbus")
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
arch/s390/pci/pci.c
arch/s390/pci/pci_event.c