stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).