linux-kernel - Re: Determining corresponding mainline patch for stable patches Re: [PATCH 5.10 125/135] drm/i915: avoid uninitialised var in eb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210819082242.GA13181@duo.ucw.cz>
Date:   Thu, 19 Aug 2021 10:22:42 +0200
From:   Pavel Machek <pavel@...x.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Theodore Ts'o <tytso@....edu>, Willy Tarreau <w@....eu>,
        Pavel Machek <pavel@...x.de>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, jason@...kstrand.net,
        Jonathan Gray <jsg@....id.au>
Subject: Re: Determining corresponding mainline patch for stable patches Re:
 [PATCH 5.10 125/135] drm/i915: avoid uninitialised var in eb_parse()

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

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)