From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Sasha Levin <sashal@kernel.org>, stable@vger.kernel.org
Subject: Re: Patches potentially missing from stable releases
Date: Wed, 28 Aug 2019 16:54:43 +0200 [thread overview]
Message-ID: <20190828145443.GA7974@kroah.com> (raw)
In-Reply-To: <1ff990c8-3ea8-5f8b-78b6-d1d91da9e508@roeck-us.net>
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
next prev parent reply other threads:[~2019-08-28 14:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 17:16 Patches potentially missing from stable releases Guenter Roeck
2019-08-27 18:10 ` Sasha Levin
2019-08-27 20:01 ` Guenter Roeck
2019-08-27 20:29 ` Greg Kroah-Hartman
2019-08-27 20:48 ` Guenter Roeck
2019-08-28 8:41 ` Greg Kroah-Hartman
2019-08-28 13:43 ` Guenter Roeck
2019-08-28 14:54 ` Greg Kroah-Hartman [this message]
2019-08-28 19:59 ` Guenter Roeck
2019-08-28 12:22 ` Sasha Levin
2019-08-29 11:00 ` Sasha Levin
2019-08-29 13:44 ` Guenter Roeck
-- strict thread matches above, loose matches on Subject: below --
2020-05-29 12:24 Henri Rosten
2020-05-29 12:46 ` Greg KH
2020-05-29 17:52 ` Henri Rosten
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190828145443.GA7974@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux@roeck-us.net \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.