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_unl=
oad` exposes a 100-second delay during kernel panics if the crash occurs wh=
ile VMBus is connecting.
- [Low] The removal of version fallback logic leaves unreachable dead code =
in `version_resp()` and renders the `next_version` field functionally obsol=
ete.
--

--- Patch [1]: [RESEND PATCH 1/6] Drivers: hv: Remove support for WS2012/20=
12R2 & 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 inl=
ine
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 =3D=3D 0) in version_r=
esp()
will always evaluate to true.=20

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 che=
ck
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 enteri=
ng
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?

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