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.
Guenter
