linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Justin Forbes <jmforbes@linuxtx.org>
To: Sasha Levin <sashal@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hugh Dickins <hughd@google.com>,
	 Linus Torvalds <torvalds@linux-foundation.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	 Miaohe Lin <linmiaohe@huawei.com>,
	LKML <linux-kernel@vger.kernel.org>,
	 Linux-MM <linux-mm@kvack.org>, Stable <stable@vger.kernel.org>
Subject: Re: 5.13.2-rc and others have many not for stable
Date: Thu, 15 Jul 2021 10:57:54 -0500	[thread overview]
Message-ID: <CAFxkdAqE0vKCyr4qFjtKmn46rHn+RJsn7m_MX6jjbN6FZcDLMA@mail.gmail.com> (raw)
In-Reply-To: <YO8DJkVzHFmPv6vz@sashalap>

On Wed, Jul 14, 2021 at 10:30 AM Sasha Levin <sashal@kernel.org> 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 decisions
> >> 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ý <mkoutny@suse.com>
> 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


  parent reply	other threads:[~2021-07-15 15:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13  5:55 Hugh Dickins
2021-07-13  6:31 ` Greg Kroah-Hartman
2021-07-13  7:20   ` Greg Kroah-Hartman
2021-07-14  1:28   ` Andrew Morton
2021-07-14  7:24     ` Jiri Slaby
2021-07-14  7:52     ` Michal Hocko
2021-07-14 15:30       ` Sasha Levin
2021-07-15  7:07         ` Michal Hocko
2021-07-15 15:57         ` Justin Forbes [this message]
2021-07-14  9:18     ` Greg Kroah-Hartman
2021-07-14 13:23       ` Greg Kroah-Hartman
2021-07-14 21:09         ` Andrew Morton
2021-07-15 10:39         ` Mel Gorman
2021-07-14 13:52       ` Sasha Levin
2021-07-14 15:35         ` Theodore Y. Ts'o
2021-07-14 15:43           ` Greg Kroah-Hartman
2021-07-14 15:46           ` Greg Kroah-Hartman
2021-07-14 17:21             ` Theodore Y. Ts'o
2021-07-14 17:34               ` Greg Kroah-Hartman
2021-07-15  9:01                 ` Geert Uytterhoeven
2021-07-15 14:47                   ` Theodore Y. Ts'o
2021-07-15 15:03                     ` Geert Uytterhoeven

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=CAFxkdAqE0vKCyr4qFjtKmn46rHn+RJsn7m_MX6jjbN6FZcDLMA@mail.gmail.com \
    --to=jmforbes@linuxtx.org \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hughd@google.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox