Re: [PATCH v2 1/1] Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:

Pre-existing issues:
- [High] Backwards teardown in `vmbus_exit()` causes failure to free IRQ ac=
tion, leading to reload failure and potential Use-After-Free of unmapped IR=
Q handler.
--

--- Patch [1]: [PATCH v2 1/1] Drivers: hv: vmbus: Skip VMBus module cleanup=
 for non-nested root partition ---
commit d186708fbf26f95dce2f00a8fed8b7ac79496439
Author: Michael Kelley <[email protected]>

Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition

This commit updates the VMBus module exit function to skip cleanup when
running in a non-nested root partition, matching the behavior of the
initialization function. This prevents memory faults and kernel panics
caused by attempting to clean up uninitialized resources during module
unload.

Closes: https://lore.kernel.org/linux-hyperv/20260721154943.A09BD1F00A3D@sm=
tp.kernel.org/

> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 6824bd7cb3c4f..88fc6add26860 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -3030,6 +3030,9 @@ static void __exit vmbus_exit(void)
>  {
>  	int cpu;
> =20
> +	if (hv_root_partition() && !hv_nested)
> +		return;
> +
>  	unregister_syscore(&hv_synic_syscore);
> =20
>  	hv_remove_kexec_handler();

[ ... ]

>  	vmbus_disconnect();
>  	if (vmbus_irq =3D=3D -1)
>  		hv_remove_vmbus_handler();
>  	else
>  		free_percpu_irq(vmbus_irq, &vmbus_evt);

[Severity: High]
This is a pre-existing issue, but does calling free_percpu_irq() here abort=
=20
and leak the irqaction?

It appears the CPUs have not yet disabled the interrupt, as=20
cpuhp_remove_state() is called much later in this function. Because=20
cpuhp_remove_state() is what triggers hv_synic_cleanup() to disable the=20
percpu IRQ on each CPU, the IRQ is still locally enabled here.

This sequence typically trips the structural safety check in=20
__free_percpu_irq() causing the free operation to abort and return NULL.=20
If the IRQ line fires after the module is unloaded, could the kernel execut=
e=20
an unmapped function pointer?

[ ... ]

>  	bus_unregister(&hv_bus);
> =20
>  	cpuhp_remove_state(hyperv_cpuhp_online);

[Severity: High]
This is related to the pre-existing issue above. Is this execution of=20
cpuhp_remove_state() too late in the teardown sequence?

This step triggers the offline callback hv_synic_cleanup() which calls=20
disable_percpu_irq(vmbus_irq). Because it runs after free_percpu_irq(),=20
the IRQ action is permanently leaked and subsequent attempts to reload the=
=20
module might fail.

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260805142421.1047=
[email protected]?part=3D1