[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MWHPR03MB2669F839E1B02D2A35D4FFE3BFFE0@MWHPR03MB2669.namprd03.prod.outlook.com>
Date: Tue, 13 Sep 2016 09:50:58 +0000
From: Dexuan Cui <decui@...rosoft.com>
To: Long Li <longli@...rosoft.com>, KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Bjorn Helgaas <bhelgaas@...gle.com>
CC: "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: RE: [PATCH 2/2] pci-hyperv: properly handle device eject
> From: devel [mailto:driverdev-devel-bounces@...uxdriverproject.org] On Behalf
> Of Long Li
> Sent: Tuesday, September 13, 2016 7:54
> ...
> A PCI_EJECT message can arrive at the same time we are calling
> pci_scan_child_bus in the workqueue for the previous PCI_BUS_RELATIONS
> message, in this case we could potentailly modify the bus from two places.
> Properly lock the bus access.
>
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1587,7 +1587,7 @@ static void hv_eject_device_work(struct work_struct
> *work)
> pdev = pci_get_domain_bus_and_slot(hpdev->hbus->sysdata.domain, 0,
> wslot);
> if (pdev) {
> - pci_stop_and_remove_bus_device(pdev);
> + pci_stop_and_remove_bus_device_locked(pdev);
> pci_dev_put(pdev);
> }
The _locked version tries to get the mutex pci_rescan_remove_lock.
But it looks pci_scan_child_bus() doesn't try to get the mutex(?), so how can
this patch make sure the 2 code paths are not running simultaneously?
Thanks,
-- Dexuan
Powered by blists - more mailing lists