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 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.
  - 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.

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.

Thanks,
J
> thanks,
>
> greg k-h