Message-ID: <CAKMK7uGStXcZXWqHJtH6jM5uy40Wo8pA7S8iHOFScTkCSM4A7Q@mail.gmail.com>
Date:   Mon, 13 Mar 2017 07:40:50 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Daniel Vetter <daniel.vetter@...el.com>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        intel-gfx <intel-gfx@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>
Subject: Re: [Intel-gfx] The i915 stable patch marking is totally broken

On Sun, Mar 12, 2017 at 11:01 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
>> So I blame this on flight level 350, but we discussed this at kernel
>> summit. Every patch we cherry-pick over comes with a "cherry-picked from
>> $sha1" line, as long as you ignore any such sha1 as duplicate you won't
>> see the same patch twice.
>
> I tried that, but that cherry-pick number doesn't seem to match up with
> anything in Linus's tree.  Where are those numbers coming from?
>
> Or there aren't numbers at all.  Look at commit:
> 8726f2faa371514fba2f594d799db95203dfeee0.  It just showed up in Linus's
> tree, and there's no "cherry-pick" number in there.  It ended up in
> 4.9.7.
>
> Hm, ok, you want me to look at the commit id and then search to see if
> it's already been merged "before".  Ah, that's crazy.  So I need to do
> that for every i915 patch?  Search backwards?  Ugh, that's a mess, no
> wonder I couldn't figure it out...

Our cherry-pick sha1 work exactly like yours: They don't make sense
when you only look at the tree a patch has been cherry-picked _to_,
since they're the sha1 from the tree they've been cherry-picked
_from_. When you clone a fresh copy of your stable tree then the
cherry-pick numbers also point nowhere. Only once you've pulled the
future tree they're from (Linus' git in your case) do they make sense.

Same for our cherry-picks, except the future tree isn't Linus' git
(we'd have managed to make sha1 collisions cheaply otherwise ...) but
the future Linus' git tree. Which is maintained by Stephen Rothwell in
linux-next. As soon as you make sure you have the latest
linux-next.git they will all resolve to something meaningful.

Not crazy going on at all :-)

>> Iirc you said you'll implement this in your scripts, and as long as we
>> never break this rule, you'll be fine. Since you seemed to have agreed to
>> a solution that would solve all your headaches I didn't bother doing
>> any changes on our side here.
>
> So if a commit says "cherry-pick", I guess I can always assume it's safe
> to add, right?  If not, _then_ I have to run the "search backwards"
> logic, right?
>
> Ok, let me think about this a bit to see if that's possible to script...

Yes, but it shouldn't be hard to avoid the linear search:

1. make sure you have the latest linux-next (to make sure all the sha1
commit-ish resolve to something meaningful). You probably want to do
that before you board a plane :-)

2. When you parse an upstream commit that says "commit cherry-picked
from $original_sha1", then add a git note for $original_sha1 that
you've seen it already and can ignore it.

3. Run that script over v4.9..v4.10 to backfill your git notes branch.

4. Make sure you sync that git notes branch (and if you use git notes
already, just use a different git notes branch name to avoid
conflicts).

5. When you spot a patch with cc: stable, check for a git note that
says you've looked at it (or one of it's cherry-picks) already, if so,
silently ignore it.

That should massively drop the ratio of failed patches, at least every
time I look at your failed patche mail I think they're just
double-applied ones. There's ofc a few patches that fail to apply, 3
months of drm/i915 development even wreak the context of simple
bugfixes sometimes, but most are not (which is btw why you don't get
replies for most of these).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Powered by blists - more mailing lists