From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Yang Shi <shy828301@gmail.com>,
Wang Yugui <wangyugui@e16-tech.com>,
Xu Yu <xuyu@linux.alibaba.com>, Jue Wang <juew@google.com>,
Matthew Wilcox <willy@infradead.org>,
Sasha Levin <sashal@kernel.org>, Alex Shi <alexs@kernel.org>,
Miaohe Lin <linmiaohe@huawei.com>, Michal Hocko <mhocko@suse.com>,
stable@vger.kernel.org
Subject: Re: mm/thp commits: please wait a few days
Date: Mon, 28 Jun 2021 14:17:33 +0200 [thread overview]
Message-ID: <YNm93fkIPrqMwHzd@kroah.com> (raw)
In-Reply-To: <6b253bc4-2562-d1bb-18f2-517cfad5d5e7@google.com>
On Fri, Jun 25, 2021 at 05:38:01PM -0700, Hugh Dickins wrote:
> On Wed, 23 Jun 2021, Hugh Dickins wrote:
> > On Wed, 23 Jun 2021, Andrew Morton wrote:
> > > On Wed, 23 Jun 2021 09:44:14 -0700 (PDT) Hugh Dickins <hughd@google.com> wrote:
> > >
> > > > > Any word on this?
> > > >
> > > > I have a "matrix" of what's needed ready, but I'm still waiting on
> > > > "I expect some more to follow in a few days time (thanks Andrew)":
> > > > I believe akpm does still intend to send them in to Linus for 5.13
> > > > this week, but they've not gone yet.
> > >
> > > Linuswards tomorrow. Is that OK?
> >
> > That's great, thanks Andrew. Then when they appear in Linus's tree,
> > I'll complete my notes and tarball, and mail GregKH in reply here.
>
> All in now, thanks: so attached is a tarball of the variants,
> and here the finalized summary of what each stable needs.
>
> 5.12.13 5.10.46 5.4.128 4.19.195 4.14.237 4.9.273
> 4.14/0001 << chpick
> 5.10/0001 << chpick << chpick << chpick << chpick
> 5.10/0002 << chpick << chpick << chpick
> 5.10/0003 << chpick << chpick << chpick
> ffc90cbb2970 << chpick << chpick
> 99fa8a48203d 5.10/0005 << chpick << chpick
> 3b77e8c8cde5 << chpick << chpick << chpick
> 732ed55823fc << chpick 5.04/0007 << chpick << chpick
> 494334e43c16 << chpick 5.04/0008 4.19/0007 << chpick
> 31657170deaf << chpick << chpick << chpick << chpick
> 22061a1ffabd 5.10/0010 5.04/0010 << chpick
> 504e070dc08f 5.10/0011 5.04/0011 4.19/0010 4.14/0008 4.09/0003
> f003c03^..a7a69d8 chpick << chpick << chpick << chpick
> fe19bd3dae3d << chpick 5.04/0022 << chpick << chpick 4.09/0004
>
> 19 recent THP-related upstream commits for 5.13:
> ffc90cbb2970 mm, thp: use head page in __migration_entry_wait()
> 99fa8a48203d mm/thp: fix __split_huge_pmd_locked() on shmem migration entry
> 3b77e8c8cde5 mm/thp: make is_huge_zero_pmd() safe and quicker
> 732ed55823fc mm/thp: try_to_unmap() use TTU_SYNC for safe splitting
> 494334e43c16 mm/thp: fix vma_address() if virtual address below file offset
> 31657170deaf mm/thp: fix page_address_in_vma() on file THP tails
> 22061a1ffabd mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page()
> 504e070dc08f mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split
> f003c03bd29e mm: page_vma_mapped_walk(): use page for pvmw->page
> 6d0fd5987657 mm: page_vma_mapped_walk(): settle PageHuge on entry
> 3306d3119cea mm: page_vma_mapped_walk(): use pmde for *pvmw->pmd
> e2e1d4076c77 mm: page_vma_mapped_walk(): prettify PVMW_MIGRATION block
> 448282487483 mm: page_vma_mapped_walk(): crossing page table boundary
> b3807a91aca7 mm: page_vma_mapped_walk(): add a level of indentation
> 474466301dfd mm: page_vma_mapped_walk(): use goto instead of while (1)
> a765c417d876 mm: page_vma_mapped_walk(): get vma_address_end() earlier
> a9a7504d9bea mm/thp: fix page_vma_mapped_walk() if THP mapped by ptes
> a7a69d8ba88d mm/thp: another PVMW_SYNC fix in page_vma_mapped_walk()
> fe19bd3dae3d mm, futex: fix shared futex pgoff on shmem huge page
>
> Antecedents which get added into some older kernels:
> 4.14/0001 91241681c62a include/linux/mmdebug.h: make VM_WARN* non-rvals
> 5.10/0001 a4055888629b (part) mm: add VM_WARN_ON_ONCE_PAGE() macro
> 5.10/0002 e0af87ff7afc mm/rmap: remove unneeded semicolon in page_not_mapped()
> 5.10/0003 b7e188ec98b1 mm/rmap: use page_not_mapped in try_to_unmap()
>
> Nothing special for 5.12.13: all 19 can be cherry-picked cleanly.
>
> Antecedents and fixedups for 5.10.46 and older:
> 5.10/0001-mm-add-VM_WARN_ON_ONCE_PAGE-macro.patch
> 5.10/0002-mm-rmap-remove-unneeded-semicolon-in-page_not_mapped.patch
> 5.10/0003-mm-rmap-use-page_not_mapped-in-try_to_unmap.patch
> 5.10/0005-mm-thp-fix-__split_huge_pmd_locked-on-shmem-migratio.patch
> 5.10/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch
> 5.10/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch
>
> Fixedups for 5.4.128 and older:
> 5.04/0007-mm-thp-try_to_unmap-use-TTU_SYNC-for-safe-splitting.patch
> 5.04/0008-mm-thp-fix-vma_address-if-virtual-address-below-file.patch
> 5.04/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch
> 5.04/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch
> 5.04/0022-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch
>
> Fixedups for 4.19.195 and older:
> 4.19/0007-mm-thp-fix-vma_address-if-virtual-address-below-file.patch
> 4.19/0010-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch
>
> (Why does matrix say not to port ffc90cbb2970 "use head page" to 4.19
> and older? It is correct, and would apply to them: but they do not
> have put_and_wait_on_page_locked(), so it may behave worse on them.)
>
> Antecedent and fixedup for 4.14.237 and older:
> 4.14/0001-include-linux-mmdebug.h-make-VM_WARN-non-rvals.patch
> 4.14/0008-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch
>
> Fixedups for 4.9.273:
> 4.09/0003-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch
> 4.09/0004-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch
>
> No backports to 4.4.273: it's too old and different for these.
Thanks so much for this, and I was able to follow the above directions
for 5.12, 5.10, and 5.4.
But things fell apart for 4.19.y, when doing the backport of the longer
series:
> f003c03^..a7a69d8 chpick << chpick << chpick << chpick
That just did not work.
So could you just send a mbox of patches (or tarball), for the 4.19,
4.14, and 4.9 trees? That would make it much easier to ensure I got
them all correct.
thanks again,
greg k-h
next prev parent reply other threads:[~2021-06-28 12:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-16 23:02 mm/thp commits: please wait a few days Hugh Dickins
2021-06-17 4:51 ` Greg Kroah-Hartman
2021-06-23 14:58 ` Greg Kroah-Hartman
2021-06-23 16:44 ` Hugh Dickins
2021-06-23 16:53 ` Greg Kroah-Hartman
2021-06-23 20:46 ` Andrew Morton
2021-06-23 21:52 ` Hugh Dickins
2021-06-26 0:38 ` Hugh Dickins
2021-06-28 12:17 ` Greg Kroah-Hartman [this message]
2021-06-28 17:12 ` Hugh Dickins
2021-06-29 3:27 ` Sasha Levin
2021-06-29 6:08 ` Greg Kroah-Hartman
2021-06-29 6:51 ` Hugh Dickins
2021-07-01 19:47 ` Hugh Dickins
2021-07-02 11:56 ` Sasha Levin
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=YNm93fkIPrqMwHzd@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=alexs@kernel.org \
--cc=hughd@google.com \
--cc=juew@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linmiaohe@huawei.com \
--cc=mhocko@suse.com \
--cc=sashal@kernel.org \
--cc=shy828301@gmail.com \
--cc=stable@vger.kernel.org \
--cc=wangyugui@e16-tech.com \
--cc=willy@infradead.org \
--cc=xuyu@linux.alibaba.com \
/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.