Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Returning -ENODEV in the root partition prevents the hv_vmbus module from loading, which breaks the loading of the mshv_root module when both are configured as loadable modules. --
--- Patch [1]: [PATCH 1/1] Drivers: hv: vmbus: Fail VMBus module init for non-nested root partition --- commit 49405a084beb024e2ba8a360ff4836611b21617d Author: Michael Kelley <[email protected]> Drivers: hv: vmbus: Fail VMBus module init for non-nested root partition This commit changes the VMBus module initialization to return -ENODEV instead of 0 when running directly in the root partition and not nested. This is intended to prevent the module from successfully loading and later causing memory faults or a panic during unload when resources were never initialized. Closes: https://lore.kernel.org/linux-hyperv/[email protected]/ > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c > index 6824bd7cb3c4f..7d5021ceea84f 100644 > --- a/drivers/hv/vmbus_drv.c > +++ b/drivers/hv/vmbus_drv.c > @@ -2982,7 +2982,7 @@ static int __init hv_acpi_init(void) > return -ENODEV; > > if (hv_root_partition() && !hv_nested) > - return 0; > + return -ENODEV; [Severity: High] Does returning -ENODEV here break dependent modules when both are built as loadable modules? If the VMBus initialization returns an error on a non-nested root partition, the hv_vmbus module will fail to load and its symbols (like hv_vmbus_exists()) will not be exported. This would prevent the mshv_root module from loading on the root partition since it depends on those exported symbols, completely breaking mshv_root functionality in its only intended environment. > > /* > * Get ACPI resources first. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
