Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Ville Syrjälä]

On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.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@verizon.com wrote:
> >> From: Ville Syrjälä <ville.syrjala@linux.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@linux.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@linux.intel.com>
> >> Signed-off-by: Sasha Levin <alexander.levin@verizon.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.

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Jani Nikula]

Cc: Greg

On Wed, 15 Nov 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.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@verizon.com wrote:
>> >> From: Ville Syrjälä <ville.syrjala@linux.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@linux.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@linux.intel.com>
>> >> Signed-off-by: Sasha Levin <alexander.levin@verizon.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").

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.

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.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

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@linux.intel.com> wrote:
> > On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.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@verizon.com wrote:
> >> >> From: Ville Syrjälä <ville.syrjala@linux.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@linux.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@linux.intel.com>
> >> >> Signed-off-by: Sasha Levin <alexander.levin@verizon.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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Ville Syrjälä]

On Fri, Nov 17, 2017 at 01:41:23PM +0100, Greg KH 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@linux.intel.com> wrote:
> > > On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.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@verizon.com wrote:
> > >> >> From: Ville Syrjälä <ville.syrjala@linux.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@linux.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@linux.intel.com>
> > >> >> Signed-off-by: Sasha Levin <alexander.levin@verizon.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...

And what were the user visible issues fixed by those backports? We
can't judge the risk/benefit ratio of a backport without knowing what
is supposedly being fixed.

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

On Fri, Nov 17, 2017 at 02:53:43PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 17, 2017 at 01:41:23PM +0100, Greg KH 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@linux.intel.com> wrote:
> > > > On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.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@verizon.com wrote:
> > > >> >> From: Ville Syrjälä <ville.syrjala@linux.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@linux.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@linux.intel.com>
> > > >> >> Signed-off-by: Sasha Levin <alexander.levin@verizon.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...
> 
> And what were the user visible issues fixed by those backports? We
> can't judge the risk/benefit ratio of a backport without knowing what
> is supposedly being fixed.

Ok fine, if you all don't want any patches automatically picked up and
backported, that's your choice, just let us know and we will add it to a
blacklist or something to prevent it.  Your development process must be
so perfect that nothing falls through the cracks and forgets to get
marked for stable...

greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Jani Nikula]

On Fri, 17 Nov 2017, Greg KH <gregkh@linuxfoundation.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@linux.intel.com> wrote:
>> > On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.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@verizon.com wrote:
>> >> >> From: Ville Syrjälä <ville.syrjala@linux.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@linux.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@linux.intel.com>
>> >> >> Signed-off-by: Sasha Levin <alexander.levin@verizon.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?

BR,
Jani.

>> 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

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Emil Velikov]

Hi Greg, all,

Pardon for the silly question, but I'm struggling to find
documentation about this new 'autoselection' process?
Where can one read up on it - be that about the tooling or the heuristics used?

I think the above may be the core reason behind the discussion here.

Thanks
Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

On Fri, Nov 17, 2017 at 03:01:08PM +0200, Jani Nikula wrote:
> On Fri, 17 Nov 2017, Greg KH <gregkh@linuxfoundation.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@linux.intel.com> wrote:
> >> > On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.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@verizon.com wrote:
> >> >> >> From: Ville Syrjälä <ville.syrjala@linux.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@linux.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@linux.intel.com>
> >> >> >> Signed-off-by: Sasha Levin <alexander.levin@verizon.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

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

On Fri, Nov 17, 2017 at 01:13:27PM +0000, Emil Velikov wrote:
> Hi Greg, all,
> 
> Pardon for the silly question, but I'm struggling to find
> documentation about this new 'autoselection' process?
> Where can one read up on it - be that about the tooling or the heuristics used?
> 
> I think the above may be the core reason behind the discussion here.

See my other email on this topic already (hint, it shouldn't matter how
the patch is selected if at least one experienced developer feels it
might be a valid stable patch...)

thanks,

greg k-h
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[alexander.levin]

On Fri, Nov 17, 2017 at 03:01:08PM +0200, Jani Nikula wrote:
>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 think there's a difference in views about the stable tag here. I
suspect that the way you see it, if you guys choose not to add a
stable tag to a commit this means that you, on purpose do *not* want
this commit to go into stable tree.

However, the stable tag is really just a sign for us saying "hey
this might need to go into stable trees", and in the same way that
having this tag doesn't guarantee that the commit will go into stable,
not adding this tag in no way guarantees that it won't.

In reality, authors and maintainers forget to tag, miss fixes, newer
authors aren't even aware of the stable process and so on, so we end
up with a good chunk of fixes that affect users but don't end up
getting fixed in stable trees just because someone forgot a simple
tag in his commit message.

The autoselection code tries to determine what a "fix" is based on
information from the commit message (so, for example, if "fix",
"panic" and "oops" appear in a commit message it's quite likely that
this commit is a fix), and various code metrics (for example, commits
that add a single condition statement and <5 lines of code are likely
to be fixes".

Past that point, it's all a judgement call on my end of whether some
commit, based on it's code, commit message, context, etc would be
something that we'd want in stable trees or not. I also accept the
fact that I may be wrong, but in those cases I'll do my best to learn
from it, fix the issue, and improve my process to prevent similar
issues in the future.

Also, if we would have strictly followed the "fix a real bug that
bothers people" rule, stable trees would mostly likely die since you'd
force users (who are usually clueless about the kernel) to do basic
triaging and report bugs on LKML, which would never happen. Instead,
we try to proactively fix bugs before users have to complain.

Consider fuzzers as an example of the above; syzkaller/trinity find
a considerable amount of bugs that don't really affect anyone, but
they still should get fixed, right?

-- 

Thanks,
Sasha