From patchwork Thu Sep 17 17:19:01 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marcelo Henrique Cerri X-Patchwork-Id: 1366300 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4BskGX5Jz8z9sRf; Fri, 18 Sep 2020 03:19:16 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1kIxYv-0002pJ-Mv; Thu, 17 Sep 2020 17:19:13 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kIxYs-0002oJ-5Y for kernel-team@lists.ubuntu.com; Thu, 17 Sep 2020 17:19:10 +0000 Received: from mail-qt1-f198.google.com ([209.85.160.198]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kIxYr-0000y5-Nh for kernel-team@lists.ubuntu.com; Thu, 17 Sep 2020 17:19:09 +0000 Received: by mail-qt1-f198.google.com with SMTP id f5so2268461qtk.11 for ; Thu, 17 Sep 2020 10:19:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=owMvD5yUd0/+rhJo/Hz0poqTIXMUpmm8WeoOd9V2yBs=; b=pF5f2F2vdQq1Ih1PwIYZe68/4eO+l38FeYmFeRCVHY4JBPpKc5FPYoyXCWn+/kZ046 SgAnMGFsbTwYfSOm6cOVPOJ4R9qsRlK7gpYV3wVkk72HNn9O/1oV2HlHju8bBfoUG7nt LosdYSPy+G/4+TAC4lN0Al9GCh6lapRRnxMaS5WZRseabqL3djGARBKp+N4dq+oMXIwH +8CJGgCJFUIykRjCSjGPDCM6L0aB5trG1NjO3ck8Qf15P/V8siVCOIkvknJ0JbAig2XN 41VM5pPV1EAdqebYBJvCL+uaBm/fWVXySbsQ/zl9doz7LoknnS+1nMF5g3aux4BH8im2 ZyfQ== X-Gm-Message-State: AOAM533TrfxvQVcuaUkuZDn5a7uDZd7QhMUe83fn6Nkr2mepDTxFPX1T uZPYP0YQR3zTMfZE/pdykDhq2LvmsRuYRwAsmWEJM3LGgLtLAKQYPiUmFpj6p07cJcIoEbcekQU 9IOGg1M0yQWS9jGBgQdNDF5i2+F5V44a0H9N6O8WP X-Received: by 2002:a0c:9c09:: with SMTP id v9mr13464483qve.57.1600363148470; Thu, 17 Sep 2020 10:19:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOgZMWgAXhwAk8m5c+X51bj0V7pGG8f8GnwJV8HyPvbGndP3JB+f3fry5qb6nKv07ciR/J0Q== X-Received: by 2002:a0c:9c09:: with SMTP id v9mr13464462qve.57.1600363148154; Thu, 17 Sep 2020 10:19:08 -0700 (PDT) Received: from valinor.lan ([201.82.186.200]) by smtp.gmail.com with ESMTPSA id r2sm209111qti.92.2020.09.17.10.19.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Sep 2020 10:19:07 -0700 (PDT) From: Marcelo Henrique Cerri To: kernel-team@lists.ubuntu.com Subject: [bionic:linux-azure-4.15, focal:linux-azure][PATCH 1/1] UBUNTU: SAUCE: Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload Date: Thu, 17 Sep 2020 14:19:01 -0300 Message-Id: <20200917171901.3360614-2-marcelo.cerri@canonical.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200917171901.3360614-1-marcelo.cerri@canonical.com> References: <20200917171901.3360614-1-marcelo.cerri@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Michael Kelley BugLink: https://bugs.launchpad.net/bugs/1895527 vmbus_wait_for_unload() looks for a CHANNELMSG_UNLOAD_RESPONSE message coming from Hyper-V. But if the message isn't found for some reason, the panic path gets hung forever. Add a timeout of 10 seconds to prevent this. Fixes: 415719160de3 ("Drivers: hv: vmbus: avoid scheduling in interrupt context in vmbus_initiate_unload()") Signed-off-by: Michael Kelley Reviewed-by: Dexuan Cui Reviewed-by: Vitaly Kuznetsov Link: https://lore.kernel.org/linux-hyperv/1600026449-23651-1-git-send-email-mikelley@microsoft.com/ Signed-off-by: Marcelo Henrique Cerri Acked-by: Ian May --- drivers/hv/channel_mgmt.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index 501c43c5851d..452307c79e4b 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -769,7 +769,7 @@ static void vmbus_wait_for_unload(void) void *page_addr; struct hv_message *msg; struct vmbus_channel_message_header *hdr; - u32 message_type; + u32 message_type, i; /* * CHANNELMSG_UNLOAD_RESPONSE is always delivered to the CPU which was @@ -779,8 +779,11 @@ static void vmbus_wait_for_unload(void) * functional and vmbus_unload_response() will complete * vmbus_connection.unload_event. If not, the last thing we can do is * read message pages for all CPUs directly. + * + * Wait no more than 10 seconds so that the panic path can't get + * hung forever in case the response message isn't seen. */ - while (1) { + for (i = 0; i < 1000; i++) { if (completion_done(&vmbus_connection.unload_event)) break;