linux-kernel - 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: <20171117135726.GB10105@kroah.com>
Date:   Fri, 17 Nov 2017 14:57:26 +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 03:01:08PM +0200, Jani Nikula wrote:
> On Fri, 17 Nov 2017, Greg KH <gregkh@...uxfoundation.org> wrote:
> > 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.
> 
> I still have no idea how this autoselect picks up patches that do *not*
> have cc: stable nor Fixes: from us. What information do you have that we
> don't for making that call?

I'll let Sasha describe how he's doing this, but in the end, does it
really matter _how_ it is done, vs. the fact that it seems to at least
one human reviewer that this is a patch that _should_ be included based
on the changelog text and the code patch?

By having this review process that Sasha is providing, he's saying
"Here's a patch that I think might be good for stable, do you object?"

If you do, great, no harm done, all is fine, the patch is dropped.  If
you don't object, just ignore the email and the patch gets merged.

If you don't want any of this to happen for your subsystem at all, then
also fine, just let us know and we will ignore it entirely.

thanks,

greg k-h