linux-kernel - Re: [Intel-gfx] The i915 stable patch marking is totally broken

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 16 Mar 2017 16:40:01 +0200
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Daniel Vetter <daniel.vetter@...el.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 Thu, 16 Mar 2017, Greg KH <gregkh@...uxfoundation.org> wrote:
> And again, you all are the only ones that have this issue.  You might
> find a handfull of patches for stable that come in twice in the rest of
> the kernel, but your "little" driver dwarfs that by an order of
> magnitude.  I really think you are doing it wrong, no one else seems to
> have this issue...

Just perhaps we have really active development with lots of diligence in
tagging fixes with Fixes: and Cc: stable, and not so many others do?

> I'll be back home next week and look into writing some scripts for this,
> but please consider just switching your "which branch does it go into
> first" model, which would really save me a ton of time, and remove
> confusion from anyone who ever runs across one of these cherry-pick
> messages.

Usually our development branches are months ahead of what's currently
happening in Linus' master. We already have tons of stuff ready for
v4.12, and at around v4.11-rc5 we start aiming at v4.13. This is what
everyone wants us to do, be ready earlier and earlier for the merge
windows.

It is *much* easier for us to grind the fixes through our CI and QA on
our development branches, make sure the fixes are good and compatible
with what's coming ahead, and that the issues stay fixed. When we merge
Linus' master and our -next, we can always trivially resolve the
conflict to what's in our -next, and the fixes are not lost. And if we
find issues with the commits, we can choose to not cherry-pick them
until they're fixed.

In the past, we did have lots of trouble with people fixing issues in
our development branches (because that's what you develop on), and the
fixes would not apply to Linus' master. We'd redo the patch, and end up
with nasty conflicts with what's in -next. We ended up stalling on fixes
in *both* branches. I think we did a much worse job getting things done
with the reverse order of applying fixes, because it was so much harder
for us.

In the end, the model is not unlike the stable workflow. It's just that
stable doesn't merge back with Linus' master.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center