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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 B9BD1C47E48 for ; Thu, 15 Jul 2021 15:58:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4B692613CF for ; Thu, 15 Jul 2021 15:58:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B692613CF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxtx.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9F95D8D00DE; Thu, 15 Jul 2021 11:58:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A91B8D00CD; Thu, 15 Jul 2021 11:58:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 849958D00DE; Thu, 15 Jul 2021 11:58:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0089.hostedemail.com [216.40.44.89]) by kanga.kvack.org (Postfix) with ESMTP id 592338D00CD for ; Thu, 15 Jul 2021 11:58:08 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 36D0C8248047 for ; Thu, 15 Jul 2021 15:58:07 +0000 (UTC) X-FDA: 78365278614.15.9F56C14 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf03.hostedemail.com (Postfix) with ESMTP id D8B6530000B5 for ; Thu, 15 Jul 2021 15:58:06 +0000 (UTC) Received: by mail-ed1-f52.google.com with SMTP id ec55so8868088edb.1 for ; Thu, 15 Jul 2021 08:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxtx.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CEb5a1maIQQgHYmKJB3wbVzZJDH16Rwjgv/JsDYzDW4=; b=NYmYiWqwZ7wq29hbL4QMhRiMKrd9SOlvd18wyaXqGvRAGRbzBaJthm960JE2gQPqOH RcKw1rkiJdrekSMIZ1VkOMQPAgyvbaVaHcSdWk6wRPQNZJ6eByaj5cC9FfJw5A5CPPIz vTp6sziLVcfp59AZG6byxXmy5nAIACQGJv140= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CEb5a1maIQQgHYmKJB3wbVzZJDH16Rwjgv/JsDYzDW4=; b=VMJxrm+5ZXHTFFIU+UhH92WyDmUPFEFZqXEyRDvdW0Pe54nZ7uN3RTXjHOK2vifOGm GGnLHUdKU6BrCk6z6jxSi8Zp6cYlGsg/uVqaHhGDjSjLiizaRhQ+j/ZnDP3RSYvBukFz AsxD7WIkuRfsjBLQHo5TF6cDGwc9H6IudssZU/3aJtGidgNlp8rNcGPG8uZ5HFY7F70S VC4tzc1IG5yeRDuSjzh4ZscX0K+7RVccie2neAD+wq0tYOD0ibQQYQfsRJVij2aqnDU/ aj8iRGiEALeFQVix05fmiG8y/pboxEMInzD02IiMZoAxZUBpE+KNYa6RMA0WmF2eQEXL 0UOw== X-Gm-Message-State: AOAM531HcgHChJtVOk78jtQbj8oqRojt6jeSoQG3S8Rg14lXWGheAEQh y1cjnliJbOG1HgT+W1BWe1569GXniSdRM8qWa4o6JQ== X-Google-Smtp-Source: ABdhPJzbx5mWi4SVxmU66lSkrv7u5T0QyI6zXoCXUYV4qW+xU3i3I1P9jmNb8I7dkhiEXZ68f70jjsvNjynRj5bSSGA= X-Received: by 2002:a50:9b06:: with SMTP id o6mr8161258edi.284.1626364685536; Thu, 15 Jul 2021 08:58:05 -0700 (PDT) MIME-Version: 1.0 References: <2b1b798e-8449-11e-e2a1-daf6a341409b@google.com> <20210713182813.2fdd57075a732c229f901140@linux-foundation.org> In-Reply-To: From: Justin Forbes Date: Thu, 15 Jul 2021 10:57:54 -0500 Message-ID: Subject: Re: 5.13.2-rc and others have many not for stable To: Sasha Levin Cc: Michal Hocko , Andrew Morton , Greg Kroah-Hartman , Hugh Dickins , Linus Torvalds , Mike Kravetz , Miaohe Lin , LKML , Linux-MM , Stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linuxtx.org header.s=google header.b=NYmYiWqw; spf=pass (imf03.hostedemail.com: domain of jmforbes@linuxtx.org designates 209.85.208.52 as permitted sender) smtp.mailfrom=jmforbes@linuxtx.org; dmarc=none X-Rspamd-Server: rspam05 X-Stat-Signature: 6up34dhbzn3yewc85epwiw774retzt99 X-Rspamd-Queue-Id: D8B6530000B5 X-HE-Tag: 1626364686-512754 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 10:30 AM Sasha Levin wrote: > > On Wed, Jul 14, 2021 at 09:52:58AM +0200, Michal Hocko wrote: > >On Tue 13-07-21 18:28:13, Andrew Morton wrote: > >> At present this -stable > >> promiscuity is overriding the (sometime carefully) considered decision= s > >> of the MM developers, and that's a bit scary. > > > >Not only scary, it is also a waste of precious time of those who > >carefuly evaluate stable tree backports. > > I'm just as concerned with the other direction: we end up missing quite > a lot of patches that are needed in practice, and no one is circling > back to make sure that we have everything we need. > It does work both ways. For those of us maintaining a kernel for a community distro, without an army of engineers actually paying attention, the current stable process has fixed more bugs than it has introduced. But it does occasionally introduce them as well. When it does, it is typically pretty easy to see where, as stable releases tend to be smaller than this set was, so only a few patches in any given subsystem or driver. If we go back to a case where only Cc: stable patches are selected, I suppose the logical step would be for maintainers like me to make sure that we send a message to stable whenever we pull a patch from upstream that fixes an actual issue that users are seeing. I don't have a strong objection to this, but it is more work. Justin > I took a peek at SUSE's tree to see how things work there, and looking > at the very latest mm/ commit: > > commit c8c7b321edcf7a7e8c22dc66e0366f72aa2390f0 > Author: Michal Koutn=C3=BD > Date: Tue May 4 11:12:10 2021 +0200 > > mm: memcontrol: fix cpuhotplug statistics flushing > (bsc#1185606). > > suse-commit: 3bba386a33fac144abf2507554cb21552acb16af > > This seems to be commit a3d4c05a4474 ("mm: memcontrol: fix cpuhotplug > statistics flushing") upstream, and I assume that it was picked because > it fixed a real bug someone cares about. > > I can maybe understand that at the time that the patch was > written/committed it didn't seem like stable@ material and thus there > was no cc to stable. > > But once someone realized it needs to be backported, why weren't we told > to take it into stable too? > > -- > Thanks, > Sasha