stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev, John Starks <jostarks@microsoft.com>,
	Michael Kelley <mikelley@microsoft.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wei Liu <wei.liu@kernel.org>
Subject: [PATCH 4.14 04/26] Drivers: hv: vmbus: Fix vmbus_wait_for_unload() to scan present CPUs
Date: Mon, 26 Jun 2023 20:11:06 +0200	[thread overview]
Message-ID: <20230626180733.851172577@linuxfoundation.org> (raw)
In-Reply-To: <20230626180733.699092073@linuxfoundation.org>

From: Michael Kelley <mikelley@microsoft.com>

commit 320805ab61e5f1e2a5729ae266e16bec2904050c upstream.

vmbus_wait_for_unload() may be called in the panic path after other
CPUs are stopped. vmbus_wait_for_unload() currently loops through
online CPUs looking for the UNLOAD response message. But the values of
CONFIG_KEXEC_CORE and crash_kexec_post_notifiers affect the path used
to stop the other CPUs, and in one of the paths the stopped CPUs
are removed from cpu_online_mask. This removal happens in both
x86/x64 and arm64 architectures. In such a case, vmbus_wait_for_unload()
only checks the panic'ing CPU, and misses the UNLOAD response message
except when the panic'ing CPU is CPU 0. vmbus_wait_for_unload()
eventually times out, but only after waiting 100 seconds.

Fix this by looping through *present* CPUs in vmbus_wait_for_unload().
The cpu_present_mask is not modified by stopping the other CPUs in the
panic path, nor should it be.

Also, in a CoCo VM the synic_message_page is not allocated in
hv_synic_alloc(), but is set and cleared in hv_synic_enable_regs()
and hv_synic_disable_regs() such that it is set only when the CPU is
online.  If not all present CPUs are online when vmbus_wait_for_unload()
is called, the synic_message_page might be NULL. Add a check for this.

Fixes: cd95aad55793 ("Drivers: hv: vmbus: handle various crash scenarios")
Cc: stable@vger.kernel.org
Reported-by: John Starks <jostarks@microsoft.com>
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Link: https://lore.kernel.org/r/1684422832-38476-1-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/hv/channel_mgmt.c |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -803,11 +803,22 @@ static void vmbus_wait_for_unload(void)
 		if (completion_done(&vmbus_connection.unload_event))
 			goto completed;
 
-		for_each_online_cpu(cpu) {
+		for_each_present_cpu(cpu) {
 			struct hv_per_cpu_context *hv_cpu
 				= per_cpu_ptr(hv_context.cpu_context, cpu);
 
+			/*
+			 * In a CoCo VM the synic_message_page is not allocated
+			 * in hv_synic_alloc(). Instead it is set/cleared in
+			 * hv_synic_enable_regs() and hv_synic_disable_regs()
+			 * such that it is set only when the CPU is online. If
+			 * not all present CPUs are online, the message page
+			 * might be NULL, so skip such CPUs.
+			 */
 			page_addr = hv_cpu->synic_message_page;
+			if (!page_addr)
+				continue;
+
 			msg = (struct hv_message *)page_addr
 				+ VMBUS_MESSAGE_SINT;
 
@@ -841,11 +852,14 @@ completed:
 	 * maybe-pending messages on all CPUs to be able to receive new
 	 * messages after we reconnect.
 	 */
-	for_each_online_cpu(cpu) {
+	for_each_present_cpu(cpu) {
 		struct hv_per_cpu_context *hv_cpu
 			= per_cpu_ptr(hv_context.cpu_context, cpu);
 
 		page_addr = hv_cpu->synic_message_page;
+		if (!page_addr)
+			continue;
+
 		msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
 		msg->header.message_type = HVMSG_NONE;
 	}



  parent reply	other threads:[~2023-06-26 18:14 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-26 18:11 [PATCH 4.14 00/26] 4.14.320-rc1 review Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 01/26] serial: lantiq: add missing interrupt ack Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 02/26] nilfs2: reject devices with insufficient block count Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 03/26] nilfs2: fix buffer corruption due to concurrent device reads Greg Kroah-Hartman
2023-06-26 18:11 ` Greg Kroah-Hartman [this message]
2023-06-26 18:11 ` [PATCH 4.14 05/26] cgroup: Do not corrupt task iteration when rebinding subsystem Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 06/26] nilfs2: prevent general protection fault in nilfs_clear_dirty_page() Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 07/26] xfrm: Linearize the skb after offloading if needed Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 08/26] net: qca_spi: Avoid high load if QCA7000 is not available Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 09/26] mmc: mtk-sd: fix deferred probing Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 10/26] mmc: omap: " Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 11/26] mmc: omap_hsmmc: " Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 12/26] mmc: usdhi60rol0: " Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 13/26] be2net: Extend xmit workaround to BE3 chip Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 14/26] netfilter: nf_tables: disallow element updates of bound anonymous sets Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 15/26] scsi: target: iscsi: Prevent login threads from racing between each other Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 16/26] HID: wacom: Add error check to wacom_parse_and_register() Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 17/26] arm64: Add missing Set/Way CMO encodings Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 18/26] nfcsim.c: Fix error checking for debugfs_create_dir Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 19/26] fbdev: imsttfb: Release framebuffer and dealloc cmap on error path Greg Kroah-Hartman
2023-06-28 21:41   ` Helge Deller
2023-06-29  7:06     ` Greg Kroah-Hartman
2023-06-29  9:39       ` Helge Deller
2023-06-26 18:11 ` [PATCH 4.14 20/26] usb: gadget: udc: fix NULL dereference in remove() Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 21/26] s390/cio: unregister device when the only path is gone Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 22/26] drm/exynos: vidi: fix a wrong error return Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 23/26] drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 24/26] drm/radeon: fix race condition UAF in radeon_gem_set_domain_ioctl Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 25/26] x86/apic: Fix kernel panic when booting with intremap=off and x2apic_phys Greg Kroah-Hartman
2023-06-26 18:11 ` [PATCH 4.14 26/26] i2c: imx-lpi2c: fix type char overflow issue when calculating the clock cycle Greg Kroah-Hartman
2023-06-27  9:04 ` [PATCH 4.14 00/26] 4.14.320-rc1 review Jon Hunter
2023-06-27 20:05 ` Chris Paterson
2023-06-27 21:31 ` Harshit Mogalapalli
2023-06-27 21:33 ` Guenter Roeck
2023-06-28  7:17 ` Naresh Kamboju
2023-06-28 13:34 ` Known bad patches from AUTOSEL was " Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230626180733.851172577@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=jostarks@microsoft.com \
    --cc=mikelley@microsoft.com \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=vkuznets@redhat.com \
    --cc=wei.liu@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).