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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 2AA82C07E9A for ; Wed, 14 Jul 2021 15:35:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CDB4661360 for ; Wed, 14 Jul 2021 15:35:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CDB4661360 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 075216B0083; Wed, 14 Jul 2021 11:35:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 025066B0085; Wed, 14 Jul 2021 11:35:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2EF96B0088; Wed, 14 Jul 2021 11:35:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0094.hostedemail.com [216.40.44.94]) by kanga.kvack.org (Postfix) with ESMTP id C12A06B0083 for ; Wed, 14 Jul 2021 11:35:44 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A0CC6144FB for ; Wed, 14 Jul 2021 15:35:43 +0000 (UTC) X-FDA: 78361593366.23.5B13094 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf06.hostedemail.com (Postfix) with ESMTP id 3DAD7801E4FB for ; Wed, 14 Jul 2021 15:35:43 +0000 (UTC) Received: from callcc.thunk.org (96-65-121-81-static.hfc.comcastbusiness.net [96.65.121.81]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16EFZTW3011784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jul 2021 11:35:30 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 8F7244202F5; Wed, 14 Jul 2021 11:35:29 -0400 (EDT) Date: Wed, 14 Jul 2021 11:35:29 -0400 From: "Theodore Y. Ts'o" To: Sasha Levin Cc: Greg Kroah-Hartman , Andrew Morton , Michal Hocko , Hugh Dickins , Linus Torvalds , Mike Kravetz , Miaohe Lin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org Subject: Re: 5.13.2-rc and others have many not for stable Message-ID: References: <2b1b798e-8449-11e-e2a1-daf6a341409b@google.com> <20210713182813.2fdd57075a732c229f901140@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3DAD7801E4FB X-Stat-Signature: 6ue9canaoyicykahh9yj75b48zftqoi4 Authentication-Results: imf06.hostedemail.com; dkim=none; spf=none (imf06.hostedemail.com: domain of tytso@mit.edu has no SPF policy when checking 18.9.28.11) smtp.mailfrom=tytso@mit.edu; dmarc=none X-HE-Tag: 1626276943-261368 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jul 14, 2021 at 09:52:53AM -0400, Sasha Levin wrote: > On Wed, Jul 14, 2021 at 11:18:14AM +0200, Greg Kroah-Hartman wrote: > > On Tue, Jul 13, 2021 at 06:28:13PM -0700, Andrew Morton wrote: > > > Alternatively I could just invent a new tag to replace the "Fixes:" > > > ("Fixes-no-backport?") to be used on patches which fix a known previous > > > commit but which we don't want backported. > > > > No please, that's not needed, I'll just ignore these types of patches > > now, and will go drop these from the queues. > > > > Sasha, can you also add these to your "do not apply" script as well? > > Sure, but I don't see how this is viable in the long term. Look at > distros that don't follow LTS trees and cherry pick only important > fixes, and see how many of those don't have a stable@ tag. I've been talking to an enterprise distro who chooses not to use the LTS releases, and it's mainly because they tried it, and there was too many regressions leading to their customers filing problem reports which get escalated to their engineers, leading to unhappy customers and extra work for their engineers. (And they have numbers to back up this assertion; this isn't just a gut feel sort of thing.) There are a couple of ways of solving it. Once is that perhaps we need to have more people testing the stable trees --- and not just for functional regressions but also for performance regressions. Ideally we would be doing lots of performance regression testing all the time, for all releases, and not just for the stable kernels, but the reality is that performance testing takes a lot of time, effort, and in some cases large amounts of expensive equipment. We have syzbot and the zero-day bot; perhaps we can see if some company might be interested in setting up a "perfbot"? Another solution (and these don't have to be mutually exclusive) might be for maintainers can explicitly state that certain patches shouldn't be backported into stable kernels. I think having an explicit "No-Backport: " might be useful, since it documents why a maintainer requested that the patch not be backported, and being an explicit tag, it makes it clear that it wasn't just a case of the developer forgetting the "Cc: stable" tag. This makes it much better than implicit rules such as "If from: akpm then don't backport" hidden in various stable maintainers' scripts. - Ted