linux-kernel - Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max

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]

Message-ID: <20171121085111.2i6glvlbgna2zxa2@phenom.ffwll.local>
Date:   Tue, 21 Nov 2017 09:51:11 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Emil Velikov <emil.l.velikov@...il.com>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        ML dri-devel <dri-devel@...ts.freedesktop.org>,
        alexander.levin@...izon.com,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9
 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

On Tue, Nov 21, 2017 at 08:58:51AM +0100, Greg KH wrote:
> On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> > Of course our CI is open, so if someone is supremely bored and wants to
> > backport more stuff for drm/i915, they could do that. But atm it doesn't
> > happen, and then having to deal with the fallout is not really great (like
> > I said, we don't really have anyone dedicated, and I much prefer we
> > fix/improve upstream).
> 
> Any reason you can't add the stable -rc tree to your CI system?

The problem is looking at results and making sure nothing breaks and
sending mails out that patches shouldn't be applied and all that. Keeping
the machines busy is the easy part.

For Linus' -rc/-fixes we do that (including human review of all the stuff
the scripts suggests we need to cherry-pick as fixes), but that's because
we have someone.

Maybe we can/should look into doing the same for the current stable (to
support fedora and other community distros a bit better). But I think
there's no way we can support all the LTS kernels out there and more than
just minimal backports.

> > For the actual products we're shipping we have dedicated teams doing the
> > backports. The upstream stable releases essentially have no value for us
> > from a customer support pov (for drivers, I guess core stuff is an
> > entirely different matter), there's not a single serious customer or
> > bigger user using that. It only costs, by spamming us with mails and bug
> > reports for stuff we didn't even nominate :-)
> 
> Any reason why you aren't sending those backported patches to the stable
> trees so that users of them can benefit from the work you are already
> doing for a limited number of "customers"?

They fail your backporting criteria. Big time, like veeeeeeery big time.

Think backporting 1k patches to get some feature. Which then means it's a
frankenkernel without any relation to any shipping stable drm/i915
release, so the backports of the bugfixes are again meaningless and
untested for anything else.

Tbh the easies for us to support is what rhel does for their updates,
which is just copy all of drivers/gpu/ into their old lts kernel and then
fix things up at the seams.

> And if your customers are not using stable kernel releases, what are
> they using for their kernels?

LTS, but with a frankenstein drm/i915. To clarify, all I'm discussing here
is just drm and drm/i915 patches, I think for core code the stable process
works reasonably well (afaiui at least).

> It sounds like you don't want to deal with the "automated" patches for
> the i915 drivers, so that's fine, we will blacklist them and ignore
> them and only deal with the patches you explicitly ask to be backported.
> As it seems like those are hard enough for you all to deal with, given
> the recent regression :)

Yeah that would at least not make it worse.

On the entire problem (that we share with amd folks, see Alex' reply) of
how to ship gpu kernel driver updates to people who care, but don't want
to track latest upstream releases, I'd love to have a solution. I just
don't see one (except tons of manual backport work).

Fundamentally the problem is that the product freeze cycle for core kernel
code (measured in years often) is just plain unsuitable for gfx drivers
(where in userspace we often end up shipping well-tested points from
master because the quarterly releases are too slow).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch