Re: [PATCH 6.12.y 0/4] crypto: ccp, KVM: SVM - missing SEV/SNP platform-init dependency + 2 bugfixes

On Mon, Aug 17, 2026 at 07:22:36AM +0200, Jinpu Wang wrote:
> On Mon, Aug 17, 2026 at 7:01 AM Greg KH <[email protected]> wrote:
> >
> > On Mon, Aug 17, 2026 at 06:51:27AM +0200, Jinpu Wang wrote:
> > > On Sat, Aug 15, 2026 at 4:33 AM Sasha Levin <[email protected]> wrote:
> > > >
> > > > > Patches 1-2 are the missing dependencies of commit 3f8f0133a5fc
> > > > > ("crypto: ccp - Move SEV/SNP Platform initialization to KVM"), already
> > > > > queued as of 6.12.97 (bb1c8464702540 on queue/6.12). That commit
> > > > > dropped SEV/SNP platform init from the CCP driver's probe path,
> > > > > expecting KVM to take over, but the counterpart commits that give KVM
> > > > > that responsibility were never queued alongside it.
> > > >
> > > > Queued the series for 6.12, thanks.
> > > >
> > > > --
> > > > Thanks,
> > > > Sasha
> > > Hi Sasha,
> > >
> > > Thanks for queueing the series.
> > >
> > > It might be worth adding a rule for the stable-kernel scripts to
> > > ensure they don't pick a single patch from the middle of an upstream
> > > patchset. This could help prevent future regressions like this one,
> > > where a commit dropped functionality in anticipation of a counterpart
> > > commit that was left behind.
> >
> > How do we "know" a patch is in the middle of a patchset just by looking
> > at the git tree?
> >
> Hi Greg,
> 
> I agree it is difficult to know purely from the git tree. For my own
> automation, I have added the following rule to my Claude.md:
> 
> Before backporting any commit, check whether it's part of a
> multi-patch series and, if so, pull in the whole series rather than a
> subset:
> 
>   - Look for series markers on the commit and its neighbors:
> Stable-dep-of: trailers, matching Suggested-by/Reviewed-by sets, same
> author + adjacent commit dates, and a shared subject-line topic.

Stable-dep-of comes from us, not in Linus's tree.

>   - Walk both directions: check commits immediately before/after it in
> upstream history from the same author/topic, not just the one commit
> named in the request.
>   - If the commit being backported removes/changes behavior that
> another sibling commit is meant to replace (e.g. moving a
> responsibility from driver A to subsystem B), verify the replacement
> sibling is already present in the target tree or is being added
> alongside it — don't land one half of a two-sided change.

Nice, but given you are using a non-determinisitic tool, odds are it
will not always work :)

We need reliability for stuff like this, not LLM messes, sorry.

> The reason for this is that we queued 3f8f0133a5fc ("crypto: ccp -
> Move SEV/SNP Platform initialization to KVM") without its counterpart
> KVM-side init/shutdown commits, leaving 6.12.97+ with no code path
> that initializes SEV/SNP, which causes a host crash on SEV-SNP VM
> start. A series-completeness check like this would have caught it.

But does it actually catch it with your tool?

Does your tool catch anything else we have missed?  We often see stable
tags in the beginning of patch series, and sometimes at the end, or in
the middle (ok just about anywhere), because that's ok.  Just look on
lkml for loads of examples of where this is just fine and if we were to
take the additional changes, that is not what the original author
wanted.

thanks,

greg k-h