Re: Determining corresponding mainline patch for stable patches Re: [PATCH 5.10 125/135] drm/i915: avoid uninitialised var in eb_parse()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

> > > Plus this adds some cognitive load on those writing these patches, which
> > > increases the global effort. It's already difficult enough to figure the
> > > appropriate Cc list when writing a fix, let's not add more burden in this
> > > chain.
> > > 
> > > ...
> > > 
> > > I'm also defending this on other projects. I find it important that
> > > efforts are reasonably shared. If tolerating 1% failures saves 20%
> > > effort on authors and adds 2% work on recipients, that's a net global
> > > win. You never completely eliminate mistakes anyway, regardless of the
> > > cost.
> > 
> > The only way I can see to square the circle would be if there was some
> > kind of script that added enough value that people naturally use it
> > because it saves *them* time, and it automatically inserts the right
> > commit metadata in some kind of standardized way.
> > 
> > I've been starting to use b4, and that's a great example of a workflow
> > that saves me time, and standardizes things as a very nice side
> > effect.  So perhaps the question is there some kind of automation that
> > saves 10-20% effort for authors *and* improves the quality of the
> > patch metadata for those that choose to use the script?
> 
> A script/tool does generate the metadata in the "correct" way, as that
> is what Sasha and I use.  It is the issue for when people do it on their
> own for various reasons and do not just point us at an upstream commit
> that can cause issues.  In those cases, people wouldn't be using any
> script anyway, so there's nothing really to do here.

I agree that submitters would need to know about the tag; OTOH I
believe that if it looked like a tag, people would be more likely to
get it right. We moved from "mention what this fixes in body" to
"Fixes: " and I believe that was an improvement.

Anyway, three new entries in stable queues have format I have not seen
before:

|ec547f971 None .: 4.19| KVM: nSVM: always intercept VMLOAD/VMSAVE when nested (CVE-2021-3656)
|dbfcc0f75 None o: 4.19| KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl (CVE-2021-3653)
|b79b08940 None o: 4.4| KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl (CVE-2021-3653)

[ upstream commit 0f923e07124df069ba68d8bb12324398f4b6b709 ]

I guess I'll simply update the script.

Best regards,
								Pavel

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux