Re: [RFC PATCH] virtio_balloon: add VIRTIO_BALLOON_F_REPORTING_PM_SAFE feature bit

Link Lin <[email protected]>
Newsgroups gmane.linux.kernel.virtualization,gmane.linux.kernel.mm,gmane.linux.kernel,gmane.linux.kernel.stable
Message-ID <CALUx4KSGtvswSARWZ9L8rbWsPmSorHaonaSWMT5UvQX9SQSqFA@mail.gmail.com>
On Thu, Aug 6, 2026 at 4:00 PM Michael S. Tsirkin <[email protected]> wrote:
>
> This makes no sense to me. So there's a bug in the guest and it crashes.
> Patch the guest.
>
> There's just no chance we'll add flags every time some guest drivers
> on some OSes have a UAF.
>
> What makes this specific bug special?
>
> Trust me when I say UAF issues e.g. around hotplug are a dime a dozen.
> Now what, let's add another one around hotplug? And so on.

Hi Michael,

Thanks for the candid feedback. I completely agree that adding feature
bits to the virtio specification to paper over guest OS bugs sets a bad
precedent, and we will drop this RFC.

To answer your question on why this felt special from our side: in public
cloud fleets with unmanaged customer images (BYOS), we cannot patch the
guest kernel. If the hypervisor turns on VIRTIO_BALLOON_F_REPORTING globally
for memory reclamation, unpatched guest kernels negotiate it blindly and
subsequently crash upon PM suspend. That makes a host-side feature rollout
act as a latent crash trigger for older guests.

We understand your point that the spec is not the place for driver bug
workarounds. We will handle this compatibility gating out-of-band in the
hypervisor / management layer instead.

Thanks for your time and review.

Sincerely,
Link
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.