From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0239D386C13 for ; Wed, 5 Aug 2026 14:24:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785939891; cv=none; b=h6Xn9t+aAG0esq6Bwx2NlEdjH0MhJNAhff9/pNv1yEyU212aWwUZiAdZ10jky63gHHDBeLB6rGAxqGVkF0F0fvpWyQB12eoZw6xIeTzCaG0FX6F5c0+E2bIJgZ8JReBCVG9QEia5E/kDUCuXrTpqcrQNSxLXXzWDE2kt5Y7v5qA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785939891; c=relaxed/simple; bh=CEc8FLPBIATMEsq8wpJPMPDmSCwONIh/JPkgFIFbI8w=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=EmCjKe7lzZI3I9md+sySdFWfp+hZZCV1vjSRVdW7k3Wg2P0SB0j7BVZCcjF2l9Dg0cLa2UFDhZN9edKHPOQfh43EtoRk4Xm5sy3A3kM86Wf3ACVRcge8s4VNbS09Aq59FNt6+uAZ3lmBz6lyIt+4Xclp6IL7vFM+xeeoGymFd4A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=IC+s1C11; arc=none smtp.client-ip=209.85.214.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IC+s1C11" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2cacb8416a1so11873675ad.1 for ; Wed, 05 Aug 2026 07:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785939872; x=1786544672; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:reply-to:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=wi22wu2w+8tiE/VeZIOwvf7Sfv8deH0UxzWDUHGi4e8=; b=IC+s1C11cVoWceLFXFTYsunqdh1kiMqSwg8pv5VRUdeXi1UZTZ7IAvR+DkjIrVySvA FNZmWRZEr5ljYaBYdvYVDu1u1qrcx4lfdo+MI/O1t5hZJ0ADFoRjR7vscKATAi723QTG AgikOPEpz9nuxE4dhMhvTsISKg0QcCKvhtppgF2zhfRvV21KVwj5aFIAqiLLwTBfaDnM tJSlFP0KIZxxyoNwvoBt8FuHDPkVUM3flB405h9OqFrDsY0f7qP60OOAMD+me8fJBz7V e0Ww59ap6e34suMyyZxIbD4jvtFFx37M8P+CGVrUPtaWCO/U+pb+NYfQvogw7Jy/bR+p l48g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785939872; x=1786544672; h=content-transfer-encoding:mime-version:reply-to:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=wi22wu2w+8tiE/VeZIOwvf7Sfv8deH0UxzWDUHGi4e8=; b=JMTa7qcHk2SefnJHPE4gWug0sj0ll0zJ4N1wBTPca3VXA3XTy68KVdFCmFEalBaZVc 0RtFNuKqeKZYpFUuQ/SOLIIYm8kT4fPyCz3SFQYdxJjg7qql8gXO9b2LxPRUYb0+FTXw fxK1CPoRdUfVvNhs07R/UadIRzrmF4XEO3EsJpQxTdF4fYqZ+9kc259Zdt8ATxjKRF9E IsykRo/WsgWQjeBxzd6YXy9EWhQzYU9btUIM6w5+UstGO6NTw6N0XBwcS3FW/g0onVci SloHL/IXRfd7Rh5B/nEKfw4vIy7DXCN+gnULxXuffAG98XX+dph1xJdnn/247urkkhtR mYQQ== X-Gm-Message-State: AOJu0YyuyEOb/nuS1NZUhwdXf9kZe5UA7FqgPlgz4NctR+Eyxs5NYw1l XSb9xzV4BSyjR9lWqcGit0maxIUgrs8kuVTCa5OKb6B1pP8laPX9th9R X-Gm-Gg: AR+sD13VoNa3MID4xdaUWQQUG4xnNUu0Gi4Rl06SCzgM/WQ3CpxAPgVe4fSh/ScQuZd Ud5QoDCUXrCn1kW2GKMQmoi2j1GcG8vidHNh2rSppM2KKRPTEEDcXkyefdPryFAtFRXnR8ibkd1 7v6GcJP56ZYiHHkI91dIgMlx8J2J1qGFDrjmdjK6LcMCIjwY6xpL2P0PdDvl5q4KbEvpLpevNmP XYELIqpYgIm7aXjMDtoY2rdRckjFE3DDR4j6Gj9KvjlcVqiZ4IVle4QRyutoSbIlgIE1GQSZODI zKSmO1O5yNwpuFAEFgrf++DdK7nQwtOKWFRQmuxLRxlexD+bIVTvshaXOmjEQ2SsQuNI3icVycZ gi7LgIAPyRoISTgJYRlPr//5eURGYlB6nImZvRZ2tvWM7OOK7LdifSs+++2deOD0MbNE6Zq+8ez YIytjmgaA+Mm32dt/OJvwCtq5RLGaD33u1vW6Iy3TQ1p4g9++jiwX/WfrJpqYlnI8+ICoeEj/uQ n/p3KdOp/toNfwKd08dR6HaHBFewvFgZjwMZKFgbvFjLKzH6eVrUbs= X-Received: by 2002:a17:902:e542:b0:2c9:c991:6ed3 with SMTP id d9443c01a7336-2d0ca7fbb60mr74436655ad.12.1785939871674; Wed, 05 Aug 2026 07:24:31 -0700 (PDT) Received: from localhost.localdomain (c-174-165-208-10.hsd1.wa.comcast.net. [174.165.208.10]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d0aa00f8a2sm18513465ad.32.2026.08.05.07.24.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 07:24:31 -0700 (PDT) From: Michael Kelley X-Google-Original-From: Michael Kelley To: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com, linux-hyperv@vger.kernel.org Cc: linux-kernel@vger.kernel.org Subject: [PATCH v2 1/1] Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition Date: Wed, 5 Aug 2026 07:24:21 -0700 Message-Id: <20260805142421.104797-1-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 Reply-To: mhklinux@outlook.com Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The VMBus module initialization function, hv_acpi_init(), currently does nothing when running in the root partition and root is not nested in another VM. But the initialization function reports success, so the VMBus module is indeed loaded. VMBus functionality is not actually needed, but the VMBus module must be loaded so that hv_vmbus_exists() can answer correctly. Furthermore, the mshv_root dependency on the VMBus module is needed as described in the commit message for 840b740a35bf ("mshv: Add conditional VMBus dependency"). Loading the VMBus module without actually initializing it causes failures if the module should later be unloaded. The module unload code tries to clean up things that were never initialized, resulting in memory faults and a panic. Fix this by having VMBus module exit function perform the same check for non-nested root partition, and do nothing in such a case, just like hv_acpi_init(). In the long run, the code that manages the Hyper-V provided SynIC should be refactored to better coordinate the requirements of root partition scenarios and normal VM scenarios, and to hopefully remove the hv_vmbus_exists() dependnecy between mshv_root and VMBus modules. Preventing the current unload failure scenario is an expediency until such a refactoring is done. Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hyperv/20260721154943.A09BD1F00A3D@smtp.kernel.org/ Fixes: 7e279d78664aa ("Drivers: hv: vmbus: skip VMBus initialization if Linux is root") Signed-off-by: Michael Kelley --- v1: https://lore.kernel.org/linux-hyperv/20260804190517.101981-1-mhklinux@outlook.com/ Changes in v2: * Use a different solution: Allow the VMBus module to load but have the unload function do nothing for non-nested root * Change the patch Subject and commit message to reflect the new approach drivers/hv/vmbus_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index e19ec73b0187..f837153427f4 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -3024,6 +3024,9 @@ static void __exit vmbus_exit(void) { int cpu; + if (hv_root_partition() && !hv_nested) + return; + unregister_syscore(&hv_synic_syscore); hv_remove_kexec_handler(); -- 2.25.1