From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 07 Mar 2019 17:42:42 -0000 Received: from mail.windriver.com ([147.11.1.11]) by Galois.linutronix.de with esmtps (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1h1x2W-0005Ho-6e for speck@linutronix.de; Thu, 07 Mar 2019 18:42:41 +0100 Received: from ALA-HCA.corp.ad.wrs.com ([147.11.189.40]) by mail.windriver.com (8.15.2/8.15.1) with ESMTPS id x27HgTUL023238 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Mar 2019 09:42:29 -0800 (PST) Subject: [MODERATED] Re: [PATCH v2 0/4] performance walnuts References: <20190305212314.203073493@infradead.org> <20190306115647.GA24219@kroah.com> <2a4e673272400fba1a2d5d6320f701e4727c7067.camel@infradead.org> <20190306180814.GB19757@kroah.com> <20190307141205.GA18722@kroah.com> From: Mark Hatle Message-ID: Date: Thu, 7 Mar 2019 11:42:27 -0600 MIME-Version: 1.0 In-Reply-To: <20190307141205.GA18722@kroah.com> Content-Type: multipart/mixed; boundary="Rrx4EA1yENfnDFLo3PRhpFZ0wGh60AcyP"; protected-headers="v1" To: speck@linutronix.de List-ID: --Rrx4EA1yENfnDFLo3PRhpFZ0wGh60AcyP Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/7/19 8:12 AM, speck for Greg KH wrote: > On Wed, Mar 06, 2019 at 12:32:52PM -0600, speck for Mark Hatle wrote: >> On 3/6/19 12:08 PM, speck for Greg KH wrote: >>> On Wed, Mar 06, 2019 at 01:02:30PM +0000, speck for David Woodhouse w= rote: >>>> On Wed, 2019-03-06 at 12:56 +0100, speck for Greg KH wrote: >>>>> On Wed, Mar 06, 2019 at 10:23:52AM +0100, speck for Thomas Gleixner= wrote: >>>>>> On Tue, 5 Mar 2019, speck for Peter Zijlstra wrote: >>>>>> >>>>>>> Or whatever shiney new name they ought to get. >>>>>>> >>>>>>> Apparently the intent is to have these patches magically appears = in source >>>>>>> repos on the 12th. >>>>>> >>>>>> I made them magically appear in the speck repo: >>>>>> >>>>>> cvs.ou.linutronix.de:linux/speck/linux tsx-5.0 >>>>>> >>>>>> and backports in the branches tsx-4.20, tsx-4.19, tsx-4.14. Git bu= ndles >>>>>> are attached. >>>>>> >>>>>> I leave the dead kernel backports to the honorable members of the = Kernel >>>>>> Necrophilia cult as usual. >>>>> >>>>> Many thanks for doing these backports. I'll use them for the stabl= e >>>>> updates next week. As for kernels older than 4.14, I'll maybe try >>>>> 4.9 on my own... >>>> >>>> Let me know if you want me to take a look. I'm travelling next week = so >>>> would have to try to squeeze it in this week. >>> >>> Do you all really care about 4.9.y anymore? I thought you all had mo= ved >>> off of it to 4.14.y already. I'll look at it tomorrow and see how ba= d >>> it looks... >> >> As painful as it is, we (and others) have customers on ancient kernels= with no >> way to upgrade for a variety of technical, regulatory and business rea= sons. But >> we don't expect you to start digging up old kernel and applying patche= s back. >=20 > And all of those kernels are almost guaranteed to be vulnerable to _WAY= _ > more than just this simple issue, unless they happen to also be taking > the stable/LTS kernel updates (or they are running a well-supported > "enterprise" kernel). In this case, the ones we are backporting to should fall under the 'well-supported' set. (This isn't the only backport of course that is ne= eded for security or simply bug fixes..) > So while it is fun for people to want to claim they "need" these > patches, what they really "need" is to fix those > technical/regulatory/business "reasons" to not ensure that they are > guaranteeing they will always have broken systems. >=20 > Yeah, I know I'm preaching to the chior here, but note, I have gotten > the US cellular carriers to now rubber-stamp LTS kernel upgrades for > Android phones. It wasn't really that hard in the end, most of them > said, "we were waiting for you to ask, of course it is ok!", all it too= k > was pushing through the layers of management who thought they knew what= > they were doing... >=20 > Sorry for the rant, but this has been a pet-peeve of mine for a long > time and something I have worked hard for the past 5 years to fix. > Please don't perpetuate the problems if you can help it. You are preaching to the choir, really. The place we see most of these issues are customers who are stuck in the = mindset (business reasons) that versions not changing (major/minor) means stabili= ty.. when really it's arbitrary or may be the opposite.. Or regulatory, such as medical where every part of the system has to be scrutinized and they only have permission to sell specific configurations= -- any change to those configurations require additional clearance, etc.. (FDA i= s working on ways to encourage upgrades without the concerns, but those rul= es are not finalized...) The technical case is rare, but were we do find it is when they're stuck = with some driver that only runs on some random version of the kernel (version = and/or bitsize) and of course they don't have the source code -- or it's written= so poorly that even with source code, you can't fix it 'easily'. (Android and cell phones is not really a concern of mine.. but I'm happy= that in general that has been assisted...) --Mark > greg k-h >=20 --Rrx4EA1yENfnDFLo3PRhpFZ0wGh60AcyP--