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

Message-ID: <20171118031547.nn7i5swliguxihip@sasha-lappy>
Date:   Sat, 18 Nov 2017 03:15:57 +0000
From:   alexander.levin@...izon.com
To:     Jani Nikula <jani.nikula@...ux.intel.com>
CC:     Greg KH <gregkh@...uxfoundation.org>,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "intel-gfx@...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:
>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