From: Mel Gorman <mgorman@techsingularity.net>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
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: Thu, 15 Jul 2021 11:39:44 +0100 [thread overview]
Message-ID: <20210715103944.GQ3809@techsingularity.net> (raw)
In-Reply-To: <YO7lZpqC4xrMPXQg@kroah.com>
On Wed, Jul 14, 2021 at 03:23:50PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 14, 2021 at 11:18:14AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Jul 13, 2021 at 06:28:13PM -0700, Andrew Morton wrote:
> > > On Tue, 13 Jul 2021 08:31:57 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > 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?
> >
> > Ok, I will do this now (goes and writes this down...)
> >
> > 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...)
>
This one at least is theoritical in nature for a backport because
PREEMPT_RT cannot be selected as no arch defines ARCH_SUPPORTS_RT
yet. If is was heading to any stable branch, it would be under
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/.
The latest kernel there is v5.10-rt and the Fixes tag is for 5.11 so that
fix would be ignored.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2021-07-15 10:39 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
2021-07-15 10:39 ` Mel Gorman [this message]
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=20210715103944.GQ3809@techsingularity.net \
--to=mgorman@techsingularity.net \
--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@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.