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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171117124123.GB24300@kroah.com>
Date:   Fri, 17 Nov 2017 13:41:23 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Jani Nikula <jani.nikula@...ux.intel.com>
Cc:     Ville Syrjälä 
        <ville.syrjala@...ux.intel.com>, alexander.levin@...izon.com,
        dri-devel@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm
 hack on VLV/CHV

On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote:
> 
> Cc: Greg
> 
> On Wed, 15 Nov 2017, Ville Syrjälä <ville.syrjala@...ux.intel.com> wrote:
> > On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@...izon.com wrote:
> >> On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
> >> >On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin@...izon.com wrote:
> >> >> From: Ville Syrjälä <ville.syrjala@...ux.intel.com>
> >> >>
> >> >> [ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
> >> >>
> >> >> The watermark should never exceed the FIFO size, so we need to
> >> >> check against the current FIFO size instead of the theoretical
> >> >> maximum when we clamp the level 0 watermark.
> >> >>
> >> >> Signed-off-by: Ville Syrjälä <ville.syrjala@...ux.intel.com>
> >> >> Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> >> >> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
> >> >> Signed-off-by: Sasha Levin <alexander.levin@...izon.com>
> >> >
> >> >Why are these patches being proposed for stable? They're not straight up
> >> >fixes for known issues, and there's always a chance that something will
> >> >break. Who is doing the qa on this?
> >> 
> >> Hi Ville,
> >> 
> >> They were selected automatically as part of a new process we're trying
> >> out. If you disagree with the selection I'd be happy to drop it.
> >
> > How does that automatic process decide that a patch should be backported?
> >
> > drm and i915 are very fast moving targets so unintended side effects from
> > backported patches is a real possibility. So I would recommend against
> > backporting anything that isn't fixing a real issue affecting users. We
> > do try to add the cc:stable to such patches.
> 
> Agreed.
> 
> First, I think an automatic backport process is against the stable
> kernel rules (e.g. "It must fix a real bug that bothers people").

It's finding lots of fixes that did bother people enough to submit a fix
for.

> Second, we can't and won't take any responsibility for backports we
> didn't indicate with Cc: stable, a Fixes: tag, or a specific backport
> request.

Ok, you all are already totally messing with my normal stable workflow,
so might as well just trust you all completely.  So let's just only take
patches that you all do send me in the normal way.  It's easy for Sasha
to filter out the drm/i915 patches from his results.

Is that ok?

> If you think there's a commit that should be backported and is known to
> fix a user visible issue (as per the stable rules!), please check with
> us first.

Um, that is what he was doing with the cc: of you all on the patch
itself that started this whole conversation...

{sigh}

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ