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 wrote:
>>>> 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 bundles
>>>>>> 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 stable
>>>>> 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 moved
>>> off of it to 4.14.y already.  I'll look at it tomorrow and see how bad
>>> 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 reasons.  But
>> we don't expect you to start digging up old kernel and applying patches back.
> 
> 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 needed
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.
> 
> 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 took
> was pushing through the layers of management who thought they knew what
> they were doing...
> 
> 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 stability..
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 is
working on ways to encourage upgrades without the concerns, but those rules 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
>