Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] State Machine Desynchronization and Type Confusion due to missing reinit_completion() -- commit 75355159caa20ef4cf6b36266c2aa7dcbac0177d Author: Berkant Koc <[email protected]> drm/hyperv: validate resolution_count and fix WIN8 fallback This commit bounds the resolution_count in SYNTHVID_RESOLUTION_RESPONSE to avoid out-of-bounds array access. It also adds a unified fallback for WIN8 default resolutions when the probe fails or max dimensions are left unpopulated. > diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c > b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c > index 051ecc5268321..c3d0ff229e3d0 100644 > --- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c > +++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c > @@ -391,8 +391,11 @@ static int hyperv_get_supported_resolution(struct > hv_device *hdev) > return -ETIMEDOUT; > } [Severity: High] This is a pre-existing issue, but does reusing hv->wait without calling reinit_completion() risk state machine desynchronization? If a prior request like hyperv_negotiate_version() times out, a delayed response could trigger complete(&hv->wait) and leave the completion signaled. When wait_for_completion_timeout() is called in this function, would it return immediately without waiting for the actual response? If a WIN10 version negotiation times out and falls back to WIN8, could a delayed WIN10 response satisfy the subsequent WIN8 wait, leading the driver to mistakenly assume the hypervisor agreed to the WIN8 protocol? Since there is no validation of msg->vid_hdr.type after waking up, could this lead to type confusion where a delayed response from an earlier request is incorrectly interpreted as the current response? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
