Thread (21 messages) 21 messages, 6 authors, 2023-03-30

RE: [PATCH 1/6] PCI: hv: fix a race condition bug in hv_pci_query_relations()

From: Long Li <longli@microsoft.com>
Date: 2023-03-28 16:49:12
Also in: linux-hyperv, linux-pci, linux-rdma, lkml

 
quoted hunk ↗ jump to hunk
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-
quoted
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
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help