On Tue, Aug 27, 2019 at 01:48:41PM -0700, Guenter Roeck wrote: > On Tue, Aug 27, 2019 at 10:29:01PM +0200, Greg Kroah-Hartman wrote: > > 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. > > > > I'd have to rewrite it to work with stable branches. Its current > primary goal is to assist the rebase of one chromeos branch to > a later upstream kernel release. I just repurposed part of it and > use the generated databases to identify patches tagged with Fixes:. > > I'll be happy to do that and make it work on stable branches in > general if you think it would add value. No worries, I can add the functionality to my local scripts that I have. If you just had happened to have it in stand-alone format, it would have saved me 30 minutes or so :) thanks for the reminder that we need to be doing this more, greg k-h
