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

[Pavel Machek]

Hi!

> > > > > From: Jonathan Gray <jsg@xxxxxxxxx>
> > > > > 
> > > > > The backport of c9d9fdbc108af8915d3f497bbdf3898bf8f321b8 to 5.10 in
> > > > > 6976f3cf34a1a8b791c048bbaa411ebfe48666b1 removed more than it should
> > > > > have leading to 'batch' being used uninitialised.  The 5.13 backport and
> > > > > the mainline commit did not remove the portion this patch adds back.
> > > > 
> > > > This patch has no upstream equivalent, right?
> > > > 
> > > > Which is okay -- it explains it in plain english, but it shows that
> > > > scripts should not simply search for anything that looks like SHA and
> > > > treat it as upsteam commit it.
> > > 
> > > Sounds like you have a broken script if you do it that way.
> > 
> > That is what you told me to do!
> > 
> > https://lore.kernel.org/stable/YQEvUay+1Rzp04SO@xxxxxxxxx/
> 
> Yes, which is fine for matching sha1 values.

I'd really like reliable / automated way to tell upstream commit from
given -stable commit. 

> > I would happily adapt my script, but there's no
> > good/documented/working way to determine upstream commit given -stable
> > commit.
> > 
> > If we could agree on
> > 
> > Commit: (SHA)
> > 
> > in the beggining of body, that would be great.
> > 
> > Upstream: (SHA)
> > 
> > in sign-off area would be even better.
> 
> What exactly are you trying to do when you find a sha1?  For some reason
> my scripts work just fine with a semi-free-form way that we currently
> have been doing this for the past 17+ years.  What are you attempting to
> do that requires such a fixed format?

Is there any problem having a fixed format? You are producing -stable
kernels, so you are not the one needing such functionality.

Anyway... We do reviews here, and we review patches on multiple
branches (4.4, 4.19, 5.10). So I'm using scripts to group backports of
the same patch together, for easier review and to flag patches that do
not have upstream equivalent for extra review. (Example of the review
file below)

There are other uses. When we were creating 5.10-cip branch, we used
automatic scripts to verify that all patches from 4.19-cip are
included in 5.10-cip. Determining mainline patch for given commit was
essential for that.

Other use was actually suggested by you: you jokingly wanted to
replace CVE-XXX with mainline commit IDs. But that needs reliable way
to determine upstream commit from stable commit to work nicely.
(And yes, we are actually trying to maintain the mapping, see for
example
https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/blob/master/issues/CVE-2016-10147.yml )

Best regards,
								Pavel


a |150198841 135cbd o: 5.10| spi: imx: mx51-ecspi: Reinstate low-speed CONFIGREG delay
a |8916a8606 53ca18 o: 5.10| spi: imx: mx51-ecspi: Fix low-speed CONFIGREG delay calculation
v |2c32af963 5c0424 o: 5.10| scsi: sr: Return correct event when media event code is 3
v |671402b0e 5c0424 o: 4.19| scsi: sr: Return correct event when media event code is 3
a |a78c94304 5c0424 o: 4.4| scsi: sr: Return correct event when media event code is 3
v |9acc1f082 c592b4 o: 5.10| media: videobuf2-core: dequeue if start_streaming fails
v |8f33cda2c c592b4 o: 4.19| media: videobuf2-core: dequeue if start_streaming fails
a |f18813d9c c592b4 .: 4.4| media: videobuf2-core: dequeue if start_streaming fails
a |da6c08058 36862c .: 5.10| ARM: dts: stm32: Disable LAN8710 EDPD on DHCOM
a |630677821 15f68f .: 5.10| ARM: dts: stm32: Fix touchscreen IRQ line assignment on DHCOM
a |f84d7d425 7199dd .: 5.10| dmaengine: imx-dma: configure the generic DMA type to make it work
a |e0188a8de d51c59 o: 5.10| net, gro: Set inner transport header offset in tcp/udp GRO hook
a |72795b111 e11e86 .: 5.10| net: dsa: sja1105: overwrite dynamic FDB entries with static ones in .port_fdb_add
a |0c548fae4 6c5fc1 .: 5.10| net: dsa: sja1105: invalidate dynamic FDB entries learned concurrently with statically added ones


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

Attachment: signature.asc
Description: PGP signature