On Thu, 18 Jan 2018 10:40:17 +0100, Greg KH wrote:

Ick, why would you be using a kernel that is about to be end-of-life anyway? Why can't you use 4.9 or even better, 4.14?

Since we mantain a custom distro, upgrading to a different major kernel version is not an option atm (QA, etc).

I was asking just because we saw that some distro based on 4.1 as well (Oracle linux, etc) have patched it on its own, so we wondered if something more upstream would have been available before starting our backporting efforts too.

Due to particular nature of vulnerability I was expected that at least this would be patched in all *current* LTS (the 3.2 that shares the same EOL date was patched like 10 days ago).

Anyway, there is no plans that I know of, sorry.

no problem

Thanks, francesco

On Fri, 19 Jan 2018 09:58:38 +0100, Greg KH wrote:

Really? What are you going to do when this goes end-of-life in 3 months? Seems like you should already be planning for that, right?

In EOL, we will be just like others that want to provide extended (custom) support, we are on our own. But that's is another problem, I guess.

If you will note, different people maintain the different trees, and they all have different amounts of time they can devote to this: https://www.kernel.org/category/releases.html

I know, and my question was way more practical: Trying to avoid to start backporting work that would been trashed after few days because it was already planned or started from someone else (and not announced to ml).

If you were to provide working patches for 4.1, I'm sure that would make things go quicker :)

Sure, I will try to do it next days :-)

Thanks a lot, francesco

On Fri, Jan 19, 2018 at 01:23:08PM +0100, Greg KH wrote:

On Fri, Jan 19, 2018 at 10:36:29AM +0000, Francesco Del Degan wrote:

...

On Fri, 19 Jan 2018 09:58:38 +0100, Greg KH wrote:

...

Really? What are you going to do when this goes end-of-life in 3 months? Seems like you should already be planning for that, right?

In EOL, we will be just like others that want to provide extended (custom) support, we are on our own. But that's is another problem, I guess.

It's a worse problem. Unless you duplicate the effort that the stable maintainers do, your machines are going to be insecure. Remember, it takes _more_ work to maintain a kernel longer, than it did previously. So soon you are going to be doing more work than I am, have fun! :)

Not only this, but not benefiting from public reviews is the main problem. In every single review I emitted for old kernels, there were several comments like "this must not be backported there", "this backport is erroneous" or "you need to also add these patches or it will be worse". And even with this I managed to sometimes break something that had to be fixed thanks to a users' report. Doing this discretely in one's garage will inevitably result in the buggiest kernel you can think of. It will lose some stability and very likely keep certain vulnerabilities incorrectly fixed (ie backport considered complete once the reproducer stops working).

And again, why can you just not update to a newer kernel version? Do you have a huge out-of-tree patchset you rely on? If so, best of luck, you should be billing whom ever forces you to use that code as it is not going to be easy.

In fact for having dealt with upgrades in our products myself, we've had some product regressions on certain kernel upgrades (which were not critical since in major branches). These were not necessarily kernel bugs, but sometimes you discover that an old script relies on a specific format of something in /proc or you're used to pass an option to a module and this option has disappeared, etc. It's never a big deal but it definitely takes some time. However I consider that the current offering of LTS kernels definitely allows to jump from LTS to LTS at each major upgrade, keeping the amount of revalidation effort reasonably low.

Quite frankly, Francesco, cut it in half, upgrade to 4.4 right now. It'll be there for a while, leaving you with enough time to properly validate other ones. The amount of difference between 4.1 and 4.4 is ridiculously low and you'll even hardly notice anything. Then you'll have more time to validate 4.9/4.14.

good luck!

Seconded :-) Willy