Re: [RESEND PATCH 1/6] Drivers: hv: Remove support for WS2012/2012R2 & Win8/8.1 version of Hyper-V

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Removing the VMBus protocol version check in `vmbus_initiate_unload` exposes a 100-second delay during kernel panics if the crash occurs while VMBus is connecting.
- [Low] The removal of version fallback logic leaves unreachable dead code in `version_resp()` and renders the `next_version` field functionally obsolete.
--

--- Patch [1]: [RESEND PATCH 1/6] Drivers: hv: Remove support for WS2012/2012R2 & Win8/8.1 version of Hyper-V ---
Note: The format of this review report has been altered to avoid quoting the
original patch code directly due to recitation restrictions. Instead of inline
comments, the findings are presented as a free-form summary below.

commit 4b263fe58a4438fc239eb817b339fbf77aa1ea23
Author: Michael Kelley <[email protected]>

Drivers: hv: Remove support for WS2012/2012R2 & Win8/8.1 version of Hyper-V

This commit removes the legacy VMBus protocol negotiation and special cases
for Windows Server 2012/2012R2 and Windows 8/8.1, as these older versions of
Hyper-V are no longer officially supported. The balloon and snapshot drivers
are also updated to drop related version fallbacks.

[Severity: Low]
In drivers/hv/hv_balloon.c, the patch removes the version fallback logic but
appears to leave behind unreachable code in version_resp(). Since
balloon_probe() now initializes dm_device.next_version to 0, if the host
rejects the version, the check for (dm->next_version == 0) in version_resp()
will always evaluate to true. 

Does this unconditionally jump to the version_error label, making the
subsequent code that prepares and sends a fallback request completely
unreachable?

Additionally, does this change render the next_version field in struct
hv_dynmem_device functionally obsolete, since it is now only ever assigned 0?

[Severity: Medium]
In drivers/hv/channel_mgmt.c, the removal of the VMBus protocol version check
in vmbus_initiate_unload() seems to expose a potential issue during kernel
panics.

Previously, the check for vmbus_proto_version < VERSION_WIN8_1 would shield
unnegotiated connections (where vmbus_proto_version is still 0) from entering
the unload wait loop. If a kernel panic occurs while vmbus_connect() is
executing, and the state is CONNECTING or CONNECTED but VMBus isn't fully
initialized, does removing this check expose the panic path to a 100-second
spin-loop delay?

Could this delay cause hardware watchdogs to reset the system before kexec
or kdump can successfully collect a crash dump?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1