On Thu, 2020-04-16 at 19:20 +0200, Greg KH wrote:
On Thu, Apr 16, 2020 at 04:40:31PM +0300, Or Gerlitz wrote:
On Thu, Apr 16, 2020 at 3:00 AM Sasha Levin sashal@kernel.org wrote:
I'd maybe point out that the selection process is based on a neural network which knows about the existence of a Fixes tag in a commit.
It does exactly what you're describing, but also taking a bunch more factors into it's desicion process ("panic"? "oops"? "overflow"? etc).
As Saeed commented, every extra line in stable / production kernel is wrong.
What? On what do you base that crazy statement on? I have 18+ years of direct experience of that being the exact opposite.
Oh, I never said such a thing .. :(
I think Or meant to say: every extra line that no one asked for.
And all i wanted to say is that it can have a catastrophic result.. I know in many cases it is working well, and i didn't say it is wrong, I am just worried about it and wanted to show an example of how it can screw up under the radar with a simple single liner patch..
IMHO it doesn't make any sense to take into stable automatically any patch that doesn't have fixes line. Do you have 1/2/3/4/5 concrete examples from your (referring to your Microsoft employee hat comment below) or other's people production environment where patches proved to be necessary but they lacked the fixes tag - would love to see them.
Oh wow, where do you want me to start. I have zillions of these.
But wait, don't trust me, trust a 3rd party. Here's what Google's security team said about the last 9 months of 2019:
- 209 known vulnerabilities patched in LTS kernels, most
without CVEs
- 950+ criticial non-security bugs fixes for device XXXX alone with LTS releases
So opt-in for these critical or _always_ in use basic kernel sections. but make the default opt-out..
We've been coaching new comers for years during internal and on- list code reviews to put proper fixes tag. This serves (A) for the upstream human review of the patch and (B) reasonable human stable considerations.
If your driver/subsystem is doing this, wonderful, just opt-out of the autosel process and you will never be bothered again.
There are many legacy devices in the kernel that are not well maintained and being rarely fixed from random users.. if a fix will be picked up to the wrong kernel, it can go unnoticed for years..
But, trust me, I think I know a bit about tagging stuff for stable kernels, and yet the AUTOSEL tool keeps finding patches that _I_ forgot to tag as such. So, don't be so sure of yourself, it's humbling :)
Let the AUTOSEL tool run, and if it finds things you don't agree with, a simple "No, please do not include this" email is all you need to do to keep it out of a stable kernel.
So far the AUTOSEL tool has found so many real bugfixes that it isn't funny. If you don't like it, fine, but it has proven itself _way_ beyond my wildest hopes already, and it just keeps getting better.
Now i really don't know what the right balance here, in on one hand, autosel is doing a great job, on the other hand we know it can screw up in some cases, and we know it will.
So we decided to make sacrifices for the greater good ? :)
greg k-h