From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50E58C433E0 for ; Thu, 18 Feb 2021 17:30:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0575764E6F for ; Thu, 18 Feb 2021 17:30:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233606AbhBRR3n (ORCPT ); Thu, 18 Feb 2021 12:29:43 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:49859 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230513AbhBROqe (ORCPT ); Thu, 18 Feb 2021 09:46:34 -0500 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 11IEXf7P014137; Thu, 18 Feb 2021 15:33:41 +0100 Date: Thu, 18 Feb 2021 15:33:41 +0100 From: Willy Tarreau To: Jari Ruusu Cc: Greg Kroah-Hartman , Scott Branden , Linux ARM , LKML , BCM Kernel Feedback Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Message-ID: <20210218143341.GB13671@1wt.eu> References: <8cf503db-ac4c-a546-13c0-aac6da5c073b@broadcom.com> <20210218113107.GA12547@1wt.eu> <602E766F.758C74D8@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <602E766F.758C74D8@users.sourceforge.net> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A1A3C433E0 for ; Thu, 18 Feb 2021 14:35:30 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C9CCD64DE8 for ; Thu, 18 Feb 2021 14:35:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C9CCD64DE8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=1wt.eu Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=pK8t/JIXvDxxr3+szS7oK4U4B1y5xajmcUSO4HCttls=; b=R+cn2C5Vyi65+GTkge2tfzuOJ IwgBhd60uF2gj2m98EeW05g8hNMdyWnCnntVW4TePTOD7t6NBX5ELCsjW6nvL6q/G80DhA8aq5GgM X/0mfDpJttVr2VH3lJoM167uCNU1urGCNTfDMQYo5UVuaBpPbsyBzf2MPfljj6zI9RHHNdETkoHeN Xwki9q60rxn3HXyBNRjpVoFL/EAJLuBwn+NUtuckE8XHzG7w2dRm0x2aIrBnS/HMW9KCa4SZbo5WE YzxA6oX7znwe4qs/y799xBEdckb4IT02s5EeN4KhoiLG0GuBbm6UeK+91L0Ayr5bHrlhklYJRtHgQ PJjj9eD0A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lCkNI-0007GY-ES; Thu, 18 Feb 2021 14:33:48 +0000 Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lCkNG-0007G8-7X for linux-arm-kernel@lists.infradead.org; Thu, 18 Feb 2021 14:33:47 +0000 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 11IEXf7P014137; Thu, 18 Feb 2021 15:33:41 +0100 Date: Thu, 18 Feb 2021 15:33:41 +0100 From: Willy Tarreau To: Jari Ruusu Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Message-ID: <20210218143341.GB13671@1wt.eu> References: <8cf503db-ac4c-a546-13c0-aac6da5c073b@broadcom.com> <20210218113107.GA12547@1wt.eu> <602E766F.758C74D8@users.sourceforge.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <602E766F.758C74D8@users.sourceforge.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210218_093346_579975_0984B28A X-CRM114-Status: GOOD ( 25.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Greg Kroah-Hartman , BCM Kernel Feedback , LKML , Linux ARM , Scott Branden Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel