From: Berkant Koc <me@berkoc.com>
To: Michael Kelley <mhklinux@outlook.com>
Cc: Saurabh Sengar <ssengar@linux.microsoft.com>,
Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
K. Y. Srinivasan <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Deepak Rawat <drawat.floss@gmail.com>,
linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] drm/hyperv: validate resolution_count and harden VSP request paths
Date: Tue, 19 May 2026 22:20:28 +0200 [thread overview]
Message-ID: <v3-reply-03-reply1.1779222028@berkoc.com> (raw)
In-Reply-To: <SN6PR02MB4157D595B990A321BFA85B40D4002@SN6PR02MB4157.namprd02.prod.outlook.com>
Hello Michael,
Thanks for the CoCo context, that lines up with what is in
vmbus_devs[] for the framebuffer device. The piecemeal approach is
what I am aiming for here.
v3 is on the list and addresses your three concrete points:
> This change should probably be a separate patch, as it's not really
> related to the bounds checking issue.
> [...]
> All that notwithstanding, I don't think your fix is needed in its
> current form.
Dropped from v3. You are right that the negotiate-version and
update-vram-location timeouts let hyperv_vmbus_probe() bail out and
free the device, so the stale-completion path is only reachable from
hyperv_vmbus_resume() after a get_supported_resolution() timeout.
That is a narrower fix and belongs in a separate patch against the
resume path, which I will send afterwards.
> Is there a separate problem here in that preferred_width and
> preferred_height are not set in the pre-WIN10 case?
Yes, separate problem, and I missed it in v2. The pre-WIN10 branch
in hyperv_connect_vsp() sets only screen_*_max and leaves preferred_*
at zero, which is inconsistent with the WIN10-failure path.
> Also, having to duplicate the fallback code is distasteful. Instead
> of having an "else" clause, maybe have a follow-up test for
> screen_width_max [...] being zero as an indicator [...]
Adopted in v3. The else branch is gone; the WIN10 path runs the probe
and the post-probe block applies the WIN8 defaults whenever
screen_width_max is still zero. One source of truth, both paths
converge on it.
> In my view, your commit message is a bit too detailed.
Rewritten in v3. The bounds check and the WIN8 fallback are now one
short paragraph each, focused on the "why".
Series: <cover.1779221339.git.me@berkoc.com>
The v3 patches carry an `Assisted-by: Claude:claude-opus-4-7
berkoc-pipeline` trailer per the kernel coding-assistants policy.
Code, analysis and review responses are mine; the model is used as
a structured reviewer under human verification.
Thanks,
Berkant
next prev parent reply other threads:[~2026-05-19 20:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-17 12:55 [PATCH 0/2] drm/hyperv: harden VMBus message parser input validation Berkant Koc
2026-05-17 12:55 ` [PATCH 1/2] drm/hyperv: validate resolution_count from host VMBus message Berkant Koc
2026-05-17 13:49 ` sashiko-bot
2026-05-17 12:55 ` [PATCH 2/2] drm/hyperv: validate VMBus packet size in receive callback Berkant Koc
2026-05-17 14:17 ` sashiko-bot
2026-05-17 14:25 ` [PATCH v2 0/2] drm/hyperv: harden VMBus message parser input validation Berkant Koc
2026-05-17 14:25 ` [PATCH v2 1/2] drm/hyperv: validate resolution_count and harden VSP request paths Berkant Koc
2026-05-17 14:47 ` sashiko-bot
2026-05-19 18:33 ` Michael Kelley
2026-05-19 20:20 ` Berkant Koc [this message]
2026-05-17 14:25 ` [PATCH v2 2/2] drm/hyperv: validate VMBus packet size in receive callback Berkant Koc
2026-05-17 15:13 ` sashiko-bot
2026-05-19 18:33 ` Michael Kelley
2026-05-19 20:20 ` Berkant Koc
2026-05-19 20:08 ` [PATCH v3 0/2] drm/hyperv: harden host message parsing Berkant Koc
2026-05-19 20:08 ` [PATCH v3 1/2] drm/hyperv: validate resolution_count and fix WIN8 fallback Berkant Koc
2026-05-19 20:55 ` sashiko-bot
2026-05-21 17:07 ` Michael Kelley
2026-05-19 20:08 ` [PATCH v3 2/2] drm/hyperv: validate VMBus packet size in receive callback Berkant Koc
2026-05-19 21:34 ` sashiko-bot
2026-05-20 13:23 ` Berkant Koc
2026-05-20 14:24 ` Michael Kelley
2026-05-21 17:19 ` Michael Kelley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=v3-reply-03-reply1.1779222028@berkoc.com \
--to=me@berkoc.com \
--cc=decui@microsoft.com \
--cc=drawat.floss@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mhklinux@outlook.com \
--cc=mripard@kernel.org \
--cc=ssengar@linux.microsoft.com \
--cc=tzimmermann@suse.de \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.