Re: [PATCH 0/2] KVM: x86: Convert all runtime WARNs to ONCE

[Sean Christopherson]

On Mon, Oct 26, 2026, Vitaly Kuznetsov wrote:
> Yosry Ahmed <yosry@xxxxxxxxxx> writes:
> 
> > On Mon, Oct 26, 2026 at 10:36 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> >>
> >> On Fri, Oct 23, 2026, Yosry Ahmed wrote:
> >> > On Thu, Oct 22, 2026 at 2:55 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> >> > >
> >> > > Convert all bare WARN() and WARN_ON() runtime usage, i.e. WARNs that aren't
> >> > > strictly scoped to module init/exit, or similar, to ONCE() variants for what
> >> > > should be fairly obvious reasons at this point.
> >> >
> >> > Do you wanna CC stable?
> >>
> >> Not really?  Maybe?  I worry that this will generate an absurd number of conflicts
> >> and also have "misses" in older kernels, to the point where it oculd do more harm
> >> than good.
> >>
> >> I could be convinced this should be tagged for stable@, though honestly it might
> >> be better to omit the automatic backport trigger and just rely on someone to
> >> "manually" provide equivalent patches.
> >
> > I can just see this ultimately preventing a DoS and if it lands on any
> > stable kernel it should be a win, but yeah probably manual backports
> > are needed :/
> 
> With my backporter's hat on, it would help significantly if we split the
> patch per-area (hyperv, [l]apic, posted_intr, vmx, svm,...). It would
> also help those who want to analyze whether the particular WARN_ON() is
> actually guest triggerable and open the corresponding CVEs.

Honestly, I don't think that's actually going to help.  Exactly which WARNs are
problematic will vary by kernel, a lot.  I.e. the set of WARNs that are spammable
*now* is not the same set that was spammable in 6.18, 6.12, 6.6, 6.1, etc.  Then
factor in different configurations and threat models, and the set of problematic
WARNs gets quite large.

So from an upstream perspective, I think we should assume everything the worst
and "fix" everything, and then do the same for LTS kernels.  I.e. backport the
concept of "never do multi-WARNs at runtime", not necessarily the literal patch.