[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <PH7PR21MB32632E889A7F589C32FE51EDCE889@PH7PR21MB3263.namprd21.prod.outlook.com>
Date: Tue, 28 Mar 2023 16:48:44 +0000
From: Long Li <longli@...rosoft.com>
To: Dexuan Cui <decui@...rosoft.com>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Jake Oshins <jakeo@...rosoft.com>,
"kuba@...nel.org" <kuba@...nel.org>, "kw@...ux.com" <kw@...ux.com>,
KY Srinivasan <kys@...rosoft.com>,
"leon@...nel.org" <leon@...nel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"lpieralisi@...nel.org" <lpieralisi@...nel.org>,
"Michael Kelley (LINUX)" <mikelley@...rosoft.com>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"robh@...nel.org" <robh@...nel.org>,
"saeedm@...dia.com" <saeedm@...dia.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
"boqun.feng@...il.com" <boqun.feng@...il.com>
CC: "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH 1/6] PCI: hv: fix a race condition bug in
hv_pci_query_relations()
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-
> hyperv.c
> index f33370b75628..b82c7cde19e6 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -3308,6 +3308,19 @@ static int hv_pci_query_relations(struct hv_device
> *hdev)
> if (!ret)
> ret = wait_for_response(hdev, &comp);
>
> + /*
> + * In the case of fast device addition/removal, it's possible that
> + * vmbus_sendpacket() or wait_for_response() returns -ENODEV but
> we
> + * already got a PCI_BUS_RELATIONS* message from the host and the
> + * channel callback already scheduled a work to hbus->wq, which can
> be
> + * running survey_child_resources() -> complete(&hbus-
> >survey_event),
> + * even after hv_pci_query_relations() exits and the stack variable
> + * 'comp' is no longer valid. This can cause a strange hang issue
> + * or sometimes a page fault. Flush hbus->wq before we exit from
> + * hv_pci_query_relations() to avoid the issues.
> + */
> + flush_workqueue(hbus->wq);
Is it possible for PCI_BUS_RELATIONS to be scheduled arrive after calling flush_workqueue(hbus->wq)?
> +
> return ret;
> }
>
> --
> 2.25.1
Powered by blists - more mailing lists