[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZG8YzuK/5+8iE8He@lpieralisi>
Date: Thu, 25 May 2023 10:14:06 +0200
From: Lorenzo Pieralisi <lpieralisi@...nel.org>
To: Dexuan Cui <decui@...rosoft.com>
Cc: bhelgaas@...gle.com, davem@...emloft.net, edumazet@...gle.com,
haiyangz@...rosoft.com, jakeo@...rosoft.com, kuba@...nel.org,
kw@...ux.com, kys@...rosoft.com, leon@...nel.org,
linux-pci@...r.kernel.org, mikelley@...rosoft.com,
pabeni@...hat.com, robh@...nel.org, saeedm@...dia.com,
wei.liu@...nel.org, longli@...rosoft.com, boqun.feng@...il.com,
ssengar@...rosoft.com, helgaas@...nel.org,
linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-rdma@...r.kernel.org, netdev@...r.kernel.org,
josete@...rosoft.com, stable@...r.kernel.org
Subject: Re: [PATCH v3 1/6] PCI: hv: Fix a race condition bug in
hv_pci_query_relations()
On Wed, Apr 19, 2023 at 07:40:32PM -0700, Dexuan Cui wrote:
> Fix the longstanding race between hv_pci_query_relations() and
> survey_child_resources() by flushing the workqueue before we exit from
> hv_pci_query_relations().
"Fix the longstanding race" is vague. Please describe the race
succinctly at least to give an idea of what the problem is.
> Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
> Signed-off-by: Dexuan Cui <decui@...rosoft.com>
> Reviewed-by: Michael Kelley <mikelley@...rosoft.com>
> Cc: stable@...r.kernel.org
> ---
>
> v2:
> Removed the "debug code".
> No change to the patch body.
> Added Cc:stable
>
> v3:
> Added Michael's Reviewed-by.
>
> drivers/pci/controller/pci-hyperv.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index f33370b756283..b82c7cde19e66 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
"A strange hang" sounds like we don't understand what's happening, it
does not feel like it is a solid understanding of the issue.
I would remove it - given that you already explain that comp is no
longer valid - that is already a bug that needs fixing.
Acked-by: Lorenzo Pieralisi <lpieralisi@...nel.org>
> + * or sometimes a page fault. Flush hbus->wq before we exit from
> + * hv_pci_query_relations() to avoid the issues.
> + */
> + flush_workqueue(hbus->wq);
> +
> return ret;
> }
>
> --
> 2.25.1
>
Powered by blists - more mailing lists