Re: Patches potentially missing from stable releases

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Aug 27, 2019 at 01:01:51PM -0700, Guenter Roeck wrote:
> On Tue, Aug 27, 2019 at 02:10:03PM -0400, Sasha Levin wrote:
> > On Tue, Aug 27, 2019 at 10:16:21AM -0700, Guenter Roeck wrote:
> > >Hi,
> > >
> > >I recently wrote a script which identifies patches potentially missing
> > >in downstream kernel branches. The idea is to identify patches backported/
> > >applied to a downstream branch for which patches tagged with Fixes: are
> > >available in the upstream kernel, but those fixes are missing from the
> > >downstream branch. The script workflow is something like:
> > >
> > >- Identify locally applied patches in downstream branch
> > >- For each patch, identify the matching upstream SHA
> > >- Search the upstream kernel for Fixes: tags with this SHA
> > >- If one or more patches with matching Fixes: tags are found, check
> > > if the patch was applied to the downstream branch.
> > >- If the patch was not applied to the downstream branch, report
> > >
> > >Running this script on chromeos-4.19 identified, not surprisingly, a number
> > >of such patches. However, and more surprisingly, it also identified several
> > >patches applied to v4.19.y for which fixes are available in the upstream
> > >kernel, but those fixes have not been applied to v4.19.y. Some of those
> > >are on the cosmetic side, but several seem to be relevant. I didn't
> > >cross-check all of them, but the ones I tried did apply to linux-4.19.y.
> > >The complete list is attached below.
> > >
> > >Question: Do Sasha's automated scripts identify such patches ? If not,
> > >would it make sense to do it ? Or is there some reason why the patches
> > >have not been applied to v4.19.y ?
> > 
> > Hey Guenter,
> > 
> > I have a very similar script with a slight difference: I don't try to
> > find just "Fixes:" tags, but rather just any reference from one patch to
> > another. This tends to catch cases where once patch states it's "a
> > similar fix to ..." and such.
> > 
> > The tricky part is that it's causing a whole bunch of false positives,
> > which takes a while to weed through - and that's where the issue is
> > right now.
> > 
> 
> I didn't see any false positives, at least not yet. Would it possibly
> make sense to start with looking at Fixes: ? After all, additional
> references (wich higher chance for false positives) can always be
> searched for later.

I used to do this "by hand" with a tiny bit of automation, but need to
step it up and do it "correctly" like you did.

If you have a pointer to your script, I'd be glad to run it here locally
to keep track of this, like I do so for patches tagged with syzbot
issues.

thanks,

greg k-h