From: Willy Tarreau <firstname.lastname@example.org> To: Jari Ruusu <email@example.com> Cc: Greg Kroah-Hartman <firstname.lastname@example.org>, Scott Branden <email@example.com>, Linux ARM <firstname.lastname@example.org>, LKML <email@example.com>, BCM Kernel Feedback <firstname.lastname@example.org> Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Date: Thu, 18 Feb 2021 15:33:41 +0100 [thread overview] Message-ID: <20210218143341.GB13671@1wt.eu> (raw) In-Reply-To: <602E766F.758C74D8@users.sourceforge.net> On Thu, Feb 18, 2021 at 04:15:11PM +0200, Jari Ruusu wrote: > Willy Tarreau wrote: > > The only set of fixes that can be trusted are the "official" stable > > kernels, because they are the only ones that are approved by the patches > > authors themselves. Adding more stuff on top of stable kernels is fine > > (and done at your own risk), but randomly dropping stuff from stable > > kernels just because you don't think you need that is totally non-sense > > and must not be done anymore! > > This may be little bit off-topic... but stable kernel.org kernels > can also bit-rot badly because of "selective" backporting... as in > anything that does not apply cleanly gets dropped regardless of > how critical they are. Sure it will. And the huge difference is that it usually gets quickly spotted and fixed. For sensitive servers I tend to apply the principle of not necessarily updating to the latest stable kernel but one or two versions before it which nobody complained about. And I'm pretty fine with skipping a significant number of updates (we all do that anyway). > I will give you one example: Intel WiFi (iwlwifi) on 4.19.y > kernel.org stable kernels is currently missing many critical > locking fixes. As a result, that in-tree iwlwifi driver causes > erratic behavior to random unrelated processes, and has been doing > so for many months now. My not-so-politically correct opinion is > that in-tree iwlwifi is completely FUBAR unless someone steps up > to do professional quality backport of those locking fixes from > upstream out-of-tree Intel version   of the driver. I see, and it happens with plenty of other drivers or subsystems. Is it in any way the stable branch's or stable maintainer's fault if someone doesn't correctly do the backporting job on their driver ? No. Is it expected that a driver works perfectly from its inclusion ? No. Is it expected that a driver can always be fixed without a significant rework that risks more breakage than fixes ? No. Some design limitations or errors can require so many changes that they're unfixable in place. I even had to *document* security issues in 2.4 because fixing them was riskier than keeping them. This happens in any piece of software. It's always been the case that some older kernels work less well than some newer ones due to limited features, partially wrong drivers etc, and getting better drivers is a valid reason for upgrading to a more recent one. However the older driver ought to continue to be maintained in a working state for those for whom it works fine. > For me > only way to get properly working WiFi on my laptop computer is to > compile that Intel out-of-tree version. Sad, but true. That's perfectly fine from my point of view. I've been doing the same for certain driver (e.g. e100 vs eepro100 15 years ago) and have been pleased to be able to stop using those out-of-tree versions. This is also in order to make this possible for those who need to do it that LTS kernels provide a lot of value: such out-of-tree drivers tend to take some time to resynchronize with latest updates, and once they're updated, you can use your machine for quite some time with them. Obviously if somemone is able to figure the required fixes for the locking bugs you mentioned above and to submit patches for stable branches, I'm sure Greg will appreciate! But maybe that's not fixable there and you need to upgrade. Usually you pick an LTS kernel for a specific hardware. If it works that's great. But you cannot expect hardware to suddenly start to work in the middle of a stable kernel. Sometimes it happens (PCI IDs) but that's basically all and that's not their purpose. Willy
next prev parent reply other threads:[~2021-02-18 17:30 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-25 19:55 Scott Branden 2021-01-26 2:50 ` Adam Borowski 2021-01-26 7:29 ` Greg Kroah-Hartman 2021-01-26 17:35 ` Florian Fainelli 2021-01-26 18:30 ` Scott Branden 2021-01-26 18:51 ` Greg Kroah-Hartman 2021-01-26 20:15 ` Willy Tarreau 2021-02-17 9:40 ` Greg Kroah-Hartman 2021-02-17 19:48 ` Scott Branden 2021-02-18 7:43 ` Greg Kroah-Hartman 2021-02-18 11:31 ` Willy Tarreau 2021-02-18 14:15 ` Jari Ruusu 2021-02-18 14:29 ` Greg Kroah-Hartman 2021-02-18 20:55 ` Pavel Machek 2021-02-18 22:43 ` Ondrej Zary 2021-02-19 8:00 ` Pavel Machek 2021-02-19 8:30 ` Greg Kroah-Hartman 2021-02-18 14:33 ` Willy Tarreau [this message] 2021-02-18 17:19 ` Jari Ruusu 2021-02-18 17:22 ` Russell King - ARM Linux admin 2021-02-18 17:44 ` Greg Kroah-Hartman 2021-02-19 7:10 ` Jari Ruusu 2021-02-19 8:22 ` Greg Kroah-Hartman 2021-02-19 10:31 ` Jari Ruusu 2021-02-19 10:37 ` Greg Kroah-Hartman 2021-02-19 10:57 ` Jari Ruusu 2021-02-19 11:16 ` Greg Kroah-Hartman 2021-02-19 15:23 ` Jari Ruusu 2021-02-20 13:29 ` Jari Ruusu 2021-02-20 16:05 ` Greg Kroah-Hartman 2021-02-20 17:06 ` Willy Tarreau 2021-02-21 11:38 ` Jari Ruusu 2021-02-19 16:50 ` Theodore Ts'o 2021-02-18 17:16 ` Florian Fainelli 2021-02-18 12:51 ` Pavel Machek 2021-02-18 16:51 ` Sasha Levin 2021-02-18 17:21 ` Florian Fainelli 2021-02-18 17:53 ` Greg Kroah-Hartman 2021-02-18 17:57 ` Florian Fainelli 2021-02-18 18:20 ` Willy Tarreau 2021-02-18 18:36 ` Greg Kroah-Hartman 2021-02-18 20:16 ` Scott Branden 2021-02-18 21:00 ` Willy Tarreau 2021-02-18 22:38 ` Scott Branden 2021-02-18 21:39 ` Sasha Levin 2021-02-18 22:00 ` Florian Fainelli 2021-02-18 22:26 ` Scott Branden 2021-02-19 8:25 ` Greg Kroah-Hartman 2021-02-19 15:05 ` Florian Fainelli 2021-02-19 15:53 ` Greg Kroah-Hartman 2021-02-19 17:44 ` Florian Fainelli 2021-02-22 14:17 ` Greg Kroah-Hartman 2021-02-18 17:42 ` Florian Fainelli 2021-02-18 18:13 ` Willy Tarreau 2021-02-18 10:04 ` Pavel Machek 2021-02-19 8:54 ` Hanjun Guo 2021-02-19 9:08 ` Greg Kroah-Hartman 2021-02-20 7:02 ` Hanjun Guo 2021-02-20 9:53 ` Greg Kroah-Hartman 2021-02-23 2:14 ` Hanjun Guo 2021-02-19 14:45 ` Nikolai Kondrashov 2021-02-26 8:03 ` Hanjun Guo 2021-02-26 11:21 ` Nikolai Kondrashov 2021-02-22 14:00 ` Nishanth Aravamudan 2021-02-22 14:24 ` Greg Kroah-Hartman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210218143341.GB13671@1wt.eu \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: 5.10 LTS Kernel: 2 or 6 years?' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).