Re: [PATCH] PCI: hv: Warn when wait_for_response() waits indefinitely

[Naman Jain]

On 8/27/2026 11:04 PM, Saurabh Singh Sengar wrote:
On Thu, Aug 27, 2026 at 04:07:06PM +0000, Michael Kelley wrote:
From: Long Li <lon...@microsoft.com> Sent: Tuesday, August 25, 2026 10:01 AM

[snip]


Basically something like this:

#define PCI_RESPONSE_WARN_TIMEOUT_SEC 300

static int wait_for_response(struct hv_device *hdev,
                   struct completion *comp) {
      unsigned long warn_at =
          jiffies + secs_to_jiffies(PCI_RESPONSE_WARN_TIMEOUT_SEC);
      bool warned = false;

      while (true) {
          if (hdev->channel->rescind) {
              dev_warn_once(&hdev->device, "The device is gone.\n");
              return -ENODEV;
          }

          if (wait_for_completion_timeout(comp, HZ / 10)) {
              if (warned || time_after_eq(jiffies, warn_at))
                  dev_warn(&hdev->device,
                       "PCI response received after prolonged wait.\n");
              return 0;
          }

          if (!warned && time_after_eq(jiffies, warn_at)) {
              dev_warn(&hdev->device,
                   "PCI still waiting for response.\n");
              warned = true;
          }
      }
}

Regards,
Naman

This looks better.


I like getting the "response received" message if the response
eventually does come in. It's a judgment call, but I would be OK
with outputting the "still waiting" message after each wait interval
rather than doing it only once. And I would make the interval smaller
than 300 seconds. Five minutes is a long time to wait and wonder
what's going on when things are hung. 60 or 120 seconds would
be OK -- a line in dmesg every 1 or 2 minutes doesn't seem like
spamming to me when something is fundamentally broken.
And probably don't expect a VM in this broken state to keep running
for hours -- the sysadmin or automatic monitoring software will
reboot it to get it working again.

I think this is a main point of this discussion. FWIK, this is not 
automatically recovered as of now, ever. With these changes, we could 
get dmesg logs completely filled with this same log, which does not add 
any value. On the other hand, I was suggesting Sahil if this problem is 
not recoverable by Azure fabric layer or other monitoring services, and 
is extremely rare and the VM is unusable, perhaps we should consider 
adding a bug/timeout in this path instead of just logging about it.

Regards,
Naman


I will also vote for repeated message as long as interval between two
messages is greater than 60 seconds.

- Saurabh


Just my $.02. Outputting the "still waiting" message only once is
also OK. Your call.

Michael