The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 05f151a73ec2b23ffbff706e5203e729a995cdc2 Mon Sep 17 00:00:00 2001
From: Dexuan Cui decui@microsoft.com Date: Mon, 4 Mar 2019 21:34:48 +0000 Subject: [PATCH] PCI: hv: Fix a memory leak in hv_eject_device_work()
When a device is created in new_pcichild_device(), hpdev->refs is set to 2 (i.e. the initial value of 1 plus the get_pcichild()).
When we hot remove the device from the host, in a Linux VM we first call hv_pci_eject_device(), which increases hpdev->refs by get_pcichild() and then schedules a work of hv_eject_device_work(), so hpdev->refs becomes 3 (let's ignore the paired get/put_pcichild() in other places). But in hv_eject_device_work(), currently we only call put_pcichild() twice, meaning the 'hpdev' struct can't be freed in put_pcichild().
Add one put_pcichild() to fix the memory leak.
The device can also be removed when we run "rmmod pci-hyperv". On this path (hv_pci_remove() -> hv_pci_bus_exit() -> hv_pci_devices_present()), hpdev->refs is 2, and we do correctly call put_pcichild() twice in pci_devices_present_work().
Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Signed-off-by: Dexuan Cui decui@microsoft.com [lorenzo.pieralisi@arm.com: commit log rework] Signed-off-by: Lorenzo Pieralisi lorenzo.pieralisi@arm.com Reviewed-by: Stephen Hemminger stephen@networkplumber.org Reviewed-by: Michael Kelley mikelley@microsoft.com Cc: stable@vger.kernel.org
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c index 95441a35eceb..30f16b882746 100644 --- a/drivers/pci/controller/pci-hyperv.c +++ b/drivers/pci/controller/pci-hyperv.c @@ -1900,6 +1900,9 @@ static void hv_eject_device_work(struct work_struct *work) sizeof(*ejct_pkt), (unsigned long)&ctxt.pkt, VM_PKT_DATA_INBAND, 0);
+ /* For the get_pcichild() in hv_pci_eject_device() */ + put_pcichild(hpdev); + /* For the two refs got in new_pcichild_device() */ put_pcichild(hpdev); put_pcichild(hpdev); put_hvpcibus(hpdev->hbus);
From: gregkh@linuxfoundation.org gregkh@linuxfoundation.org Sent: Wednesday, May 15, 2019 1:35 AM To: Dexuan Cui decui@microsoft.com; lorenzo.pieralisi@arm.com; Michael Kelley mikelley@microsoft.com; stephen@networkplumber.org Cc: stable@vger.kernel.org Subject: FAILED: patch "[PATCH] PCI: hv: Fix a memory leak in hv_eject_device_work()" failed to apply to 4.14-stable tree
The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 05f151a73ec2b23ffbff706e5203e729a995cdc2 Mon Sep 17 00:00:00 2001 From: Dexuan Cui decui@microsoft.com Date: Mon, 4 Mar 2019 21:34:48 +0000 Subject: [PATCH] PCI: hv: Fix a memory leak in hv_eject_device_work()
When a device is created in new_pcichild_device(), hpdev->refs is set to 2 (i.e. the initial value of 1 plus the get_pcichild()).
When we hot remove the device from the host, in a Linux VM we first call hv_pci_eject_device(), which increases hpdev->refs by get_pcichild() and then schedules a work of hv_eject_device_work(), so hpdev->refs becomes 3 (let's ignore the paired get/put_pcichild() in other places). But in hv_eject_device_work(), currently we only call put_pcichild() twice, meaning the 'hpdev' struct can't be freed in put_pcichild().
Add one put_pcichild() to fix the memory leak.
The device can also be removed when we run "rmmod pci-hyperv". On this path (hv_pci_remove() -> hv_pci_bus_exit() -> hv_pci_devices_present()), hpdev->refs is 2, and we do correctly call put_pcichild() twice in pci_devices_present_work().
Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Signed-off-by: Dexuan Cui decui@microsoft.com [lorenzo.pieralisi@arm.com: commit log rework] Signed-off-by: Lorenzo Pieralisi lorenzo.pieralisi@arm.com Reviewed-by: Stephen Hemminger stephen@networkplumber.org Reviewed-by: Michael Kelley mikelley@microsoft.com Cc: stable@vger.kernel.org
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c index 95441a35eceb..30f16b882746 100644 --- a/drivers/pci/controller/pci-hyperv.c +++ b/drivers/pci/controller/pci-hyperv.c @@ -1900,6 +1900,9 @@ static void hv_eject_device_work(struct work_struct *work) sizeof(*ejct_pkt), (unsigned long)&ctxt.pkt, VM_PKT_DATA_INBAND, 0);
- /* For the get_pcichild() in hv_pci_eject_device() */
- put_pcichild(hpdev);
- /* For the two refs got in new_pcichild_device() */ put_pcichild(hpdev); put_pcichild(hpdev); put_hvpcibus(hpdev->hbus);
Hi, I backported the patch for linux-4.14.y.
Please use the attached patch, which is [PATCH 1/3]
Thanks, -- Dexuan
On Wed, May 15, 2019 at 11:18:56PM +0000, Dexuan Cui wrote:
Hi, I backported the patch for linux-4.14.y.
Please use the attached patch, which is [PATCH 1/3]
Hi Dexuan,
For future reference, please keep the commit message in the backported patch same as the upstream one, unless you want to add additional information about the backport, in which case just add it to the commit message rather than replacing it.
I've cleaned up the commit message and queued it up for 4.14, thank you.
-- Thanks, Sasha
From: Sasha Levin sashal@kernel.org Sent: Thursday, May 16, 2019 5:42 PM On Wed, May 15, 2019 at 11:18:56PM +0000, Dexuan Cui wrote:
Hi, I backported the patch for linux-4.14.y.
Please use the attached patch, which is [PATCH 1/3]
Hi Dexuan,
For future reference, please keep the commit message in the backported patch same as the upstream one, unless you want to add additional information about the backport, in which case just add it to the commit message rather than replacing it.
I've cleaned up the commit message and queued it up for 4.14, thank you.
Sasha
Thanks, Sasha!
I thought only using the concise one-line commit info would be better . :-)
I'll follow the rule in the future.
-- Dexuan
linux-stable-mirror@lists.linaro.org