Re: [PATCH v4 0/9] KVM: TDX: Enable VM-DoS Prevention Features for TDX
Sean Christopherson <[email protected]>
| Newsgroups | dev.linux.lists.linux-coco,org.kernel.vger.kvm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Aug 19, 2026, Rick P Edgecombe wrote: > On Wed, 2026-08-19 at 16:03 -0700, Sean Christopherson wrote: > > > To me this is not a valid reason. Sashiko is great, but we can't let false > > > positives drive the patches. Given that the series is so big now, I'd think > > > it would be better to leave 6 and 9 for follow up, so we can focus on the > > > core thing. > > > > Hmm, I disagree. If the consolidation weren't here, I'd absolutely ask for > > it. This is new feature enabling. Yeah, it happens to be tagged for stable, > > but at the end of the day, it's new feature enabling. And it's standard > > operation procedure to do cleanups and dedup code as part of new feature > > enabling. > > > > If anything patch 6 should be patch 1, but that's a minor detail I can sort > > out when applying (assuming another version isn't required). > > Ok. But you disagree with dropping the patch? Dropping the patch. > Or that avoiding sashiko reports of existing issues is an invalid reason to > change the series? > > I think it's good to discuss a bit how to handle sashiko scenarios. Like we do any other code review: use common sense and follow established best practices. If a human reviewer pointed out an existing bug, we would analyze the situation and make a judgment call as to whether it's better to send a standalone fix or roll a fix into a new version of the series. If we decided to fix the issue separately, and then a human brought up the same pre-existing issue in a future revision, we would point them at the fix or the previous discussion (or if it was the same human, (politely?) tell them to go away). The only differences is that Sashiko is noisier because is doesn't (yet?) remember what feedback it gave in the past, often doesn't look at the patches later in the series, and doesn't (yet?) respond to emails so telling Sashiko to shut up about a particular pre-existing issue isn't effective. But to be very explicit: don't include a patch *purely* to suppress Sashiko's rediscovery of existing issues.