On Wed, Aug 28, 2019 at 06:43:43AM -0700, Guenter Roeck wrote:
On 8/28/19 1:41 AM, Greg Kroah-Hartman wrote:
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 :)
I'll do it anyway. Already almost done. You are apparently better than me, though. It takes me a bit more than 30 minutes, but then I am using the opportunity to improve the scripts a bit. I'll publish the whole thing at github once complete.
I'm not saying it would be 30 minutes "from scratch", as I already have most of this all working already as I am doing this today for the syzbot stuff: https://github.com/gregkh/gregkh-linux/blob/master/scripts/syzbot_search
A "real" script would be wonderful to have, thanks!
thanks,
greg k-h