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=-11.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 245BCC11F67 for ; Tue, 13 Jul 2021 06:32:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C84F7611AB for ; Tue, 13 Jul 2021 06:32:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C84F7611AB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 09CF06B0095; Tue, 13 Jul 2021 02:32:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0746C6B0096; Tue, 13 Jul 2021 02:32:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7E556B0098; Tue, 13 Jul 2021 02:32:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0139.hostedemail.com [216.40.44.139]) by kanga.kvack.org (Postfix) with ESMTP id C246C6B0095 for ; Tue, 13 Jul 2021 02:32:02 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C3CCD1852300A for ; Tue, 13 Jul 2021 06:32:01 +0000 (UTC) X-FDA: 78356594442.01.C86F335 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf01.hostedemail.com (Postfix) with ESMTP id 4E1F15009352 for ; Tue, 13 Jul 2021 06:32:01 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id CA33E60724; Tue, 13 Jul 2021 06:31:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1626157920; bh=iMuvmIE0kAoqY9keTpiEumLIadU2ExRBtXI7HPoxV+A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QZyZLJFWMbKUpdZR2ktXGQyRrkH8KUoIj3itFZpEhEsIoQEceXSfEF7LuzuEVjNA4 UNtjwYiRjeTRWt1sERJVbSEXF2GMLgojKgW9oISVpZ5YFLKhEhD8wn+1M9lOJBv6Z8 CjAWInjMXqODzs9pwemPaALNT/7qMibmMSDDLouE= Date: Tue, 13 Jul 2021 08:31:57 +0200 From: Greg Kroah-Hartman To: Hugh Dickins Cc: Andrew Morton , 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: References: <2b1b798e-8449-11e-e2a1-daf6a341409b@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2b1b798e-8449-11e-e2a1-daf6a341409b@google.com> Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=QZyZLJFW; spf=pass (imf01.hostedemail.com: domain of gregkh@linuxfoundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org X-Rspamd-Server: rspam05 X-Stat-Signature: p9aqfa3a5m3p8gnrzxj3c1mzdwomdyma X-Rspamd-Queue-Id: 4E1F15009352 X-HE-Tag: 1626157921-911331 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 Mon, Jul 12, 2021 at 10:55:01PM -0700, Hugh Dickins wrote: > On Mon, 12 Jul 2021, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 5.13.2 release. > > There are 800 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed, 14 Jul 2021 06:02:46 +0000. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.13.2-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.13.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > ------------- > > Pseudo-Shortlog of commits: > > > > Greg Kroah-Hartman > > Linux 5.13.2-rc1 > > Hi Greg, > > Sorry to be making waves, but please, what's up with the 5.13.2-rc, > 5.12.17-rc, 5.10.50-rc, 5.4.132-rc stable release candidates? They show the problem that we currently have where maintainers wait at the end of the -rc cycle and keep valid fixes from being sent to Linus. They "bunch up" and come out only in -rc1 and so the first few stable releases after -rc1 comes out is huge. It's been happening for the past few years and only getting worse. These stable releases are proof of that, the 5.13.2-rc release was the largest we have ever done and it broke one of my scripts because of it :( I know personally I do this for my subsystems, having fixes that are trivial things batch up for -rc1 just because they are generally not worth getting into -final. But that is not the case with many other subsystems as you can see by these huge patch sequences. > 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. 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? 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. We are glad to drop any patch added to a -rc release, just let us know. We are also glad to revert them later on if a developer/maintainer does not catch them in time before a release happens. thanks, greg k-h