All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Sasha Levin <sashal@kernel.org>
Cc: stable@vger.kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: Patches potentially missing from stable releases
Date: Tue, 27 Aug 2019 13:01:51 -0700	[thread overview]
Message-ID: <20190827200151.GA19618@roeck-us.net> (raw)
In-Reply-To: <20190827181003.GR5281@sasha-vm>

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.

Thanks,
Guenter

> I try to review a few each week and queue them up together with my
> autosel patches, but I guess I should step it up a bit.
> 
> Let me go over my list and try to catch up - I think I'll have time in
> the very near future.
> 
> --
> Thanks,
> Sasha

  reply	other threads:[~2019-08-27 20:01 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 [this message]
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
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=20190827200151.GA19618@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=gregkh@linuxfoundation.org \
    --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.