[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BN3PR03MB2227A05E023D644952FE95A1CEF10@BN3PR03MB2227.namprd03.prod.outlook.com>
Date: Wed, 14 Sep 2016 16:31:18 +0000
From: Long Li <longli@...rosoft.com>
To: Dexuan Cui <decui@...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
> -----Original Message-----
> From: Dexuan Cui
> Sent: Tuesday, September 13, 2016 10:45 PM
> 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; linux-kernel@...r.kernel.org; linux-
> pci@...r.kernel.org
> Subject: RE: [PATCH 2/2] pci-hyperv: properly handle device eject
>
> > From: Long Li
> > Sent: Wednesday, September 14, 2016 1:41
> >
> > I think this code is safe here. If we reach the code
> > pci_stop_and_remove_bus_device_locked, create_root_hv_pci_bus() is
> > already called.
>
> When hv_pci_probe() -> create_root_hv_pci_bus() -> pci_scan_child_bus()
> is running on one cpu, I think nothing in the current code can prevent
> hv_eject_device_work() -> pci_stop_and_remove_bus_device_locked()
> from running on another cpu?
>
> The race window is pretty small however.
This is a valid race condition. I'll work on a V2 patch. Thanks!
>
> Thanks,
> -- Dexuan
Powered by blists - more mailing lists