linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>, Michal Hocko <mhocko@kernel.org>,
	Hugh Dickins <hughd@google.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Miaohe Lin <linmiaohe@huawei.com>,
	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
Date: Wed, 14 Jul 2021 14:09:11 -0700	[thread overview]
Message-ID: <20210714140911.6c45f8f4a9b129ed36bb9d06@linux-foundation.org> (raw)
In-Reply-To: <YO7lZpqC4xrMPXQg@kroah.com>

On Wed, 14 Jul 2021 15:23:50 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> > But it really feels odd that you all take the time to add a "Hey, this
> > fixes this specific commit!" tag in the changelog, yet you do not
> > actually want to go and fix the kernels that have that commit in it.
> > This is an odd signal to others that watch the changelogs for context
> > clues.  Perhaps you might not want to do that anymore.
> 
> I looked at some of these patches and it seems really odd to me that you
> all are marking them with Fixes: tags, but do not want them backported.
> 
> First example is babbbdd08af9 ("mm/huge_memory.c: don't discard hugepage
> if other processes are mapping it")
> 
> Why is this not ok to backport?
> 
> Also what about e6be37b2e7bd ("mm/huge_memory.c: add missing read-only
> THP checking in transparent_hugepage_enabled()")?
> 
> And 41eb5df1cbc9 ("mm: memcg/slab: properly set up gfp flags for objcg
> pointer array")?
> 
> And 6acfb5ba150c ("mm: migrate: fix missing update page_private to
> hugetlb_page_subpool")?
> 
> And 832b50725373 ("mm: mmap_lock: use local locks instead of disabling
> preemption")? (the RT people want that...)
> 
> And f7ec104458e0 ("mm/page_alloc: fix counting of managed_pages")?
> 
> Do you want to rely on systems where these fixes are not applied?
> 
> I can understand if you all want to send them to us later after they
> have been "tested out" in Linus's tree, that's fine, but to just not
> want them applied at all feels odd to me.

Broadly speaking: end-user impact.  If we don't have reports of the
issue causing a user-visible problem and we don't expect such things to
occur, don't backport.  Why risk causing some regression when we cannot
identify any benefit?  (and boy do my fingers get tired asking people
to describe the user-visible effects of the bug they claim to have fixed!)

Of course, screwups can happen and user-useful patches may be passed
over.


  reply	other threads:[~2021-07-14 21:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13  5:55 5.13.2-rc and others have many not for stable 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
2021-07-14  9:18     ` Greg Kroah-Hartman
2021-07-14 13:23       ` Greg Kroah-Hartman
2021-07-14 21:09         ` Andrew Morton [this message]
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=20210714140911.6c45f8f4a9b129ed36bb9d06@linux-foundation.org \
    --to=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@kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).