Re: [PATCH v2 4/6] drm_hyperv: Remove support for synth video protocol of old Hyper-V hosts

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

Pre-existing issues:
- [High] Missing `reinit_completion()` and lack of transaction ID or messag=
e type verification causes data races and state machine corruption when VMB=
us requests time out and receive late responses.
--

--- Patch [4]: [PATCH v2 4/6] drm_hyperv: Remove support for synth video pr=
otocol of old Hyper-V hosts ---
commit d7a97b3cab0a3a58ec215d4c2c173f39a5e2648a
Author: Michael Kelley <[email protected]>

drm_hyperv: Remove support for synth video protocol of old Hyper-V hosts

This commit removes support for synthetic video protocols from Hyper-V
hosts older than Windows 10. It replaces the version negotiation loop
with a single negotiation for the WIN10 version.

> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c b/drivers/gpu/drm/=
hyperv/hyperv_drm_proto.c
> index f0ef627b4898a..1d09bba1efdd8 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
[ ... ]
> @@ -581,11 +559,9 @@ int hv_drm_connect_vsp(struct hv_device *hdev)
> =20
>  	hv->screen_depth =3D SYNTHVID_DEPTH_WIN8;
> =20
> -	if (hv_drm_version_ge(hv->synthvid_version, SYNTHVID_VERSION_WIN10)) {
> -		ret =3D hv_drm_get_supported_resolution(hdev);
> -		if (ret)
> -			drm_err(dev, "Failed to get supported resolution from host, use defau=
lt\n");
> -	}
> +	ret =3D hv_drm_get_supported_resolution(hdev);
> +	if (ret)
> +		drm_err(dev, "Failed to get supported resolution from host, use defaul=
t\n");

[Severity: High]
This is a pre-existing issue, but if hv_drm_get_supported_resolution() times
out here, is it safe to proceed and ignore the error?

hv_drm_get_supported_resolution() issues a request via hv->init_buf and wai=
ts
using wait_for_completion_timeout(&hv->wait, ...). If a timeout occurs, the
error is logged but the driver initialization continues.

Later, if another VMBus request is made using the same shared hv->init_buf
(such as in hv_drm_update_vram_location()), a concurrently arriving late
response to the original resolution query could cause a data race:

hv_drm_receive_sub() would overwrite hv->init_buf via memcpy() while the new
request is being built, corrupting the outgoing message. It also signals
complete(&hv->wait), which could prematurely wake up the new request's wait
loop, falsely accepting the old response since transaction IDs aren't verif=
ied.

Does the driver need to reinitialize completions or discard late responses
after a timeout to prevent this state machine corruption?

> =20
>  	if (!hv->screen_width_max) {
>  		hv->screen_width_max =3D SYNTHVID_WIDTH_WIN8;

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