From: Dexuan Cui <decui@xxxxxxxxxxxxx> Sent: Wednesday, March 20, 2019 5:36 PM > > > From: Michael Kelley <mikelley@xxxxxxxxxxxxx> > > > ... > > > diff --git a/drivers/pci/controller/pci-hyperv.c > > > @@ -1776,6 +1776,10 @@ static void pci_devices_present_work(struct > > work_struct *work) > > > hpdev = list_first_entry(&removed, struct hv_pci_dev, > > > list_entry); > > > list_del(&hpdev->list_entry); > > > + > > > + if (hpdev->pci_slot) > > > + pci_destroy_slot(hpdev->pci_slot); > > > > The code is inconsistent in whether hpdev->pci_slot is set to NULL after calling > > pci_destory_slot(). > Here, in pci_devices_present_work(), it's unnecessary to set it to NULL, > Because: > 1) the "hpdev" is removed from hbus->children and it can not be seen > elsewhere; > 2) the "hpdev" struct is freed in the below put_pcichild(): > > while (!list_empty(&removed)) { > hpdev = list_first_entry(&removed, struct hv_pci_dev, > list_entry); > list_del(&hpdev->list_entry); > > if (hpdev->pci_slot) > pci_destroy_slot(hpdev->pci_slot); > > put_pcichild(hpdev); > } > > > Patch 2 in this series does set it to NULL, but this code does not. > In Patch2, i.e. in the code path hv_pci_remove() -> hv_pci_remove_slots(), > we must set hpdev->pci_slot to NULL, otherwise, later, due to > hv_pci_remove() -> hv_pci_bus_exit() -> > hv_pci_devices_present() with the zero "relations", we'll double-free the > "hpdev" struct in pci_devices_present_work() -- see the above. > > > And the code in hv_eject_device_work() does not set it to NULL. > It's unnecessary to set hpdev->pci_slot to NULL in hv_eject_device_work(), > Because in hv_eject_device_work(): > 1) the "hpdev" is removed from hbus->children and it can not be seen > elsewhere; > 2) the "hpdev" struct is freed at the end of hv_eject_device_work() with my > first patch: [PATCH 1/3] PCI: hv: Fix a memory leak in hv_eject_device_work(). > > > It looks like all the places that test the value of hpdev->pci_slot or call > > pci_destroy_slot() are serialized, so it looks like it really doesn't matter. But > > when > > the code is inconsistent about setting to NULL, it always makes me wonder if > > there > > is a reason. > > > > Michael > Reviewed-by: Michael Kelley <mikelley@xxxxxxxxxxxxx> _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel