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=-6.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 4E9A2C11F67 for ; Wed, 14 Jul 2021 01:28:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D09396117A for ; Wed, 14 Jul 2021 01:28:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D09396117A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0275E6B0088; Tue, 13 Jul 2021 21:28:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F40416B008C; Tue, 13 Jul 2021 21:28:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE18E6B0092; Tue, 13 Jul 2021 21:28:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0086.hostedemail.com [216.40.44.86]) by kanga.kvack.org (Postfix) with ESMTP id B4E386B0088 for ; Tue, 13 Jul 2021 21:28:16 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id AC4AB80331E9 for ; Wed, 14 Jul 2021 01:28:15 +0000 (UTC) X-FDA: 78359457750.08.00A1A05 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf28.hostedemail.com (Postfix) with ESMTP id 3331690000A2 for ; Wed, 14 Jul 2021 01:28:15 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id DCAED6128B; Wed, 14 Jul 2021 01:28:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1626226094; bh=1Kq4a+B3sv2xmZ3srIAChXuQ/hkTCRS9tvGxI9qxX8o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XgCjkHJYFA/5vw/DvI6zk8UZ1aqrcF7YGM2yT3HL34SM9KQBwYYX32sIeboXDLaE8 bpp+NJ9bHKY0FVX8vure3zT70Hkg2JMfIy+JRdhj91DgEv5gDdlzbka3xYxif/mmbJ 6m0iYWhtJnBZjO2zGBr+twF+gJMOhIiFbw1376Oc= Date: Tue, 13 Jul 2021 18:28:13 -0700 From: Andrew Morton To: Greg Kroah-Hartman Cc: Hugh Dickins , Linus Torvalds , Sasha Levin , Michal Hocko , 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: <20210713182813.2fdd57075a732c229f901140@linux-foundation.org> In-Reply-To: References: <2b1b798e-8449-11e-e2a1-daf6a341409b@google.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3331690000A2 X-Stat-Signature: 9diqfkybije4sbrb4irmfxyumfecp97n Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=XgCjkHJY; spf=pass (imf28.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1626226095-511922 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 Tue, 13 Jul 2021 08:31:57 +0200 Greg Kroah-Hartman wrote: > > > Amongst the 2000+ patches posted today, there are a significant number > > of them Signed-off-by Andrew, Signed-off-by Linus, Signed-off-by Sasha: > > yet never Cc'ed to stable (nor even posted as AUTOSELs, I think). > > > > Am I out of date? I thought that had been agreed not to happen: > > https://lore.kernel.org/linux-mm/20190808000533.7701-1-mike.kravetz@oracle.com/ > > is the thread I found when I looked for confirmation, but I believe the > > same has been agreed before and since too. > > > > Andrew goes to a lot of trouble to establish which Fixes from his tree > > ought to go to stable. Of course there will be exceptions which we > > later decide should go in after all; but it's worrying when there's a > > wholesale breach like this, and I think most of them should be dropped. > > > > To pick on just one of many examples (sorry Miaohe!), a patch that > > surprises me, but I've not had time to look into so far, and would > > not want accelerated into X stable releases, 385/800 > > > > > Miaohe Lin > > > mm/shmem: fix shmem_swapin() race with swapoff > > Sasha, and I, take patches from Linus's tree like the above one that > have "Fixes:" tags in them as many many maintainers do not remember to > put "cc: stable" on their patches. As do many many developers. I always check. > The above patch says it fixes a problem in the 5.1 kernel release, so > Sasha queued it up for 5.10, 5.12, and 5.13. Odds are he should have > also sent a "FAILED" notice for 5.4, but we don't always do that for > patches only with a Fixes tag all the time as we only have so much we > can do... > > So is that tag incorrect? If not, why was it not cc: stable? Why is it > not valid for a stable release? Usually because we judged that the seriousness of the problem did not justify the risk & churn of backporting its fix. > So far, all automated testing seems to > show that there are no regressions in these releases with these commits > in them. If there was a problem, how would it show up? > > And as far as I know, mm/ stuff is still not triggered by the AUTOSEL > bot, but that is not what caused this commit to be added to a stable > release. > > Trying to keep a "do not apply" list for Fixes: tags only is much harder > for both of us as we do these semi-manually and review them > individually. Trying to remember what subsystem only does Fixes tags > yet really doesn't mean it is an impossible task. Well, it shouldn't be super hard to skip all patches which have Fixes:, Signed-off-by:akpm and no cc:stable? I'd really really prefer this, please. At present this -stable promiscuity is overriding the (sometime carefully) considered decisions of the MM developers, and that's a bit scary. I've actually been spending the past couple of years believing that if I left off cc:stable, the fix wasn't going to go into -stable! 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.