From: Florian Fainelli <f.fainelli@gmail.com> To: Willy Tarreau <w@1wt.eu>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Scott Branden <scott.branden@broadcom.com> Cc: 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 09:16:34 -0800 [thread overview] Message-ID: <311de080-d9b7-4907-8d5b-3edc3c471932@gmail.com> (raw) In-Reply-To: <20210218113107.GA12547@1wt.eu> On 2/18/2021 3:31 AM, Willy Tarreau wrote: > On Thu, Feb 18, 2021 at 08:43:48AM +0100, Greg Kroah-Hartman wrote: >> On Wed, Feb 17, 2021 at 11:48:21AM -0800, Scott Branden wrote: >>> Other difficulty with the LTS version is the frequency it is updated. > > What a stange statement! So basically if fixes come in quickly so that > customers are not exposed too long to well-known issues, it's a difficulty ? > I guess by now every serious OS vendor provides at least weekly fixes, and > at an era where devices are all interconnected, it's really necessary > (unless of course you don't care about your customer's security). > >>> We would not >>> pickup the changes that frequently to test. A quarterly, bi-annually, or when a critical fix >>> is identified would be when we update and perform any meaningful testing when in maintainence. >> >> How are you "identifying" these "critical fixes"? We fix at least one >> known security issue a week, and probably multitudes of >> unknown-at-this-moment ones. How are you determining when you need to >> send a new base kernel update off to your customers? At such long >> intervals it feels like anyone using your kernel releases is woefully >> insecure. > > +1! It seems like this dangerous practice will never end :-( > > Let me explain a personal experience. When I took over 2.6.32 many years > ago, Greg asked me to adapt to the new maintenance process involving the > patch reviews. At first I feared that it would increase my amount of work. > And it did. But I also discovered how important these reviews were, because > I started to get lots of "don't take this one in this version" and more > importantly "if you merge this you'll need these ones as well". And very > quickly I discovered how bogus the branches I used to maintain before > had been, given the high feedback ratio! > > So based on this experience, I can assure anyone doing cherry-picks in > their garage from LTS kernels that they're doing crap and that they must > not distribute these kernels to anyone because THESE KERNELS ARE DANGEROUS. > It's even very easy to introduce vulnerabilities by doing this! Yes absolutely. > > 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. Well, let us say that the authors had a chance to review the backports being applied but given the volume maybe they did and silence means agreement, or maybe they did not get a chance to review those changes. Let us say that the trust level of the offical stable kernels is just the highest of all kernels that are out there? > 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! Yes, definitively not setting up for success. -- Florian
next prev parent reply other threads:[~2021-02-18 18:58 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 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 [this message] 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=311de080-d9b7-4907-8d5b-3edc3c471932@gmail.com \ --to=f.fainelli@gmail.com \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=scott.branden@broadcom.com \ --cc=w@1wt.eu \ --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).