LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Jari Ruusu <jariruusu@users.sourceforge.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Scott Branden <scott.branden@broadcom.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>
Subject: Re: 5.10 LTS Kernel: 2 or 6 years?
Date: Thu, 18 Feb 2021 15:33:41 +0100
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 [1] [2] 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

  parent reply index

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 \
    --to=w@1wt.eu \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jariruusu@users.sourceforge.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=scott.branden@broadcom.com \
    /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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git