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