v2 folds two further issues into patch 1 that the sashiko-bot review
pointed out on v1:
1. The resolution_count bounds check in v1 returned -ENODEV, but
hyperv_connect_vsp() only logged a warning and continued without
setting hv->screen_width_max / height_max / preferred_*. That
left dev->mode_config.max_width and max_height at 0, which made
drm_internal_framebuffer_create() reject every userspace
framebuffer with -EINVAL. v2 falls back to the WIN8 defaults on
that error path, matching the pre-WIN10 branch.
2. The three sequential VSP requests in hyperv_connect_vsp()
(negotiate version, update VRAM location, get supported
resolution) all wait on the same hv->wait completion without
calling reinit_completion() between requests. A delayed
complete() after a wait_for_completion_timeout() can leak into
the next request and let it parse stale data out of
hv->init_buf. v2 calls reinit_completion() before each send.
Patch 2 is unchanged from v1.
v1: https://lore.kernel.org/r/[email protected]
Berkant Koc (2):
drm/hyperv: validate resolution_count and harden VSP request paths
drm/hyperv: validate VMBus packet size in receive callback
drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 32 ++++++++++++++++++-----
1 file changed, 26 insertions(+), 6 deletions(-)
base-commit: 6916d5703ddf9a38f1f6c2cc793381a24ee914c6
--
2.47.3
