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] [day] [month] [year] [list]

Message-ID: <20170412125756.GA2515@kroah.com>
Date:   Wed, 12 Apr 2017 14:57:56 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Dave Airlie <airlied@...il.com>,
        Daniel Vetter <daniel.vetter@...el.com>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        stable <stable@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Intel-gfx] The i915 stable patch marking is totally broken

On Wed, Apr 12, 2017 at 02:48:55PM +0200, Greg KH wrote:
> On Mon, Mar 13, 2017 at 07:49:59AM +0100, Daniel Vetter wrote:
> > On Sun, Mar 12, 2017 at 10:52 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> > > Why don't the maintainers know which tree to put them in when they are
> > > submitted?  As an example, if I get a patch that needs to go to Linus, I
> > > put it in my usb-linus branch, and when it hits a -rc release, I then
> > > merge that -rc back into my usb-next branch.  So I end up with about 2-3
> > > merges to -rc every release, which isn't bad and doesn't cause any
> > > duplication issues.
> > >
> > > Seems that most other subsystems also do this as well.
> > 
> > We do know (mostly) where a patch should go to, and we do push a
> > backmerge every 1-2 weeks or so, too.
> > 
> > The reason why we've started to require that every bugfix for drm/i915
> > land in -next first is fairly similar to why you insist every bugfix
> > must be in Linus' tree: Without that patches get lost. Well, they
> > don't get lost intentionally (they're all still in the git log for us
> > due to backmerges), but we did lose some in the horrible resulting
> > conflicts. Insisting that we have them in our -next branch means the
> > backmerges can be resolved with git merge -x ours.
> > 
> > And in the end this is how it's done byalmost everyone: You push to
> > master and cherry-pick over to stable/release branches. Most projects
> > don't apply bugfixes to the stable branch and then backmerge to their
> > master branch, because it would result in pure chaos. You don't do
> > that either for stable kernel. It's just that for most subsystems the
> > resulting conflict gallore of using backmerges is fairly manageable
> > (it's getting into the no-fun territory with drm core too, but still
> > ok), whereas drm/i915 is just too much, moving too fast, to make that
> > a working model.
> 
> Ok, I agree that your code is moving too fast for the "normal" stable
> model here.  I just tried to apply a potential 17 patches and only 8
> applied.  That's not a good percentage.

Ok, the last remaining ones (all 6) in my queue, did apply cleanly, so
your percentage went up a bit more, but it's still the worst of any part
of the kernel and I don't think this is working as-is.

greg k-h