Re: [PATCH 1/7] mm/thp: fix __split_huge_pmd_locked() on shmem migration entry

From: Yang Shi
Date: Thu Jun 03 2021 - 17:27:26 EST


On Tue, Jun 1, 2021 at 2:05 PM Hugh Dickins <hughd@xxxxxxxxxx> wrote:
>
> Stressing huge tmpfs page migration racing hole punch often crashed on the
> VM_BUG_ON(!pmd_present) in pmdp_huge_clear_flush(), with DEBUG_VM=y kernel;
> or shortly afterwards, on a bad dereference in __split_huge_pmd_locked()
> when DEBUG_VM=n. They forgot to allow for pmd migration entries in the
> non-anonymous case.
>
> Full disclosure: those particular experiments were on a kernel with more
> relaxed mmap_lock and i_mmap_rwsem locking, and were not repeated on the
> vanilla kernel: it is conceivable that stricter locking happens to avoid
> those cases, or makes them less likely; but __split_huge_pmd_locked()
> already allowed for pmd migration entries when handling anonymous THPs,
> so this commit brings the shmem and file THP handling into line.
>
> Are there more places that need to be careful about pmd migration entries?
> None hit in practice, but several of those is_huge_zero_pmd() tests were
> done without checking pmd_present() first: I believe a pmd migration entry
> could end up satisfying that test. Ah, the inversion of swap offset, to
> protect against L1TF, makes that impossible on x86; but other arches need
> the pmd_present() check, and even x86 ought not to apply pmd_page() to a
> swap-like pmd. Fix those instances; __split_huge_pmd_locked() was not
> wrong to be checking with pmd_trans_huge() instead, but I think it's
> clearer to use pmd_present() in each instance.
>
> And while there: make it clearer to the eye that the !vma_is_anonymous()
> and is_huge_zero_pmd() blocks make early returns (and don't return void).
>
> Fixes: e71769ae5260 ("mm: enable thp migration for shmem thp")
> Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx>
> Cc: <stable@xxxxxxxxxxxxxxx>
> ---
> mm/huge_memory.c | 38 ++++++++++++++++++++++++--------------
> mm/pgtable-generic.c | 5 ++---
> 2 files changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 63ed6b25deaa..9fb7b47da87e 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1587,9 +1587,6 @@ bool madvise_free_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> goto out_unlocked;
>
> orig_pmd = *pmd;
> - if (is_huge_zero_pmd(orig_pmd))
> - goto out;
> -
> if (unlikely(!pmd_present(orig_pmd))) {
> VM_BUG_ON(thp_migration_supported() &&
> !is_pmd_migration_entry(orig_pmd));
> @@ -1597,6 +1594,9 @@ bool madvise_free_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> }
>
> page = pmd_page(orig_pmd);
> + if (is_huge_zero_page(page))
> + goto out;
> +
> /*
> * If other processes are mapping this page, we couldn't discard
> * the page unless they all do MADV_FREE so let's skip the page.
> @@ -1676,7 +1676,7 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> spin_unlock(ptl);
> if (is_huge_zero_pmd(orig_pmd))
> tlb_remove_page_size(tlb, pmd_page(orig_pmd), HPAGE_PMD_SIZE);
> - } else if (is_huge_zero_pmd(orig_pmd)) {
> + } else if (pmd_present(orig_pmd) && is_huge_zero_pmd(orig_pmd)) {

If it is a huge zero migration entry, the code would fallback to the
"else". But IIUC the "else" case doesn't handle the huge zero page
correctly. It may mess up the rss counter.

> zap_deposited_table(tlb->mm, pmd);
> spin_unlock(ptl);
> tlb_remove_page_size(tlb, pmd_page(orig_pmd), HPAGE_PMD_SIZE);
> @@ -2044,7 +2044,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
> count_vm_event(THP_SPLIT_PMD);
>
> if (!vma_is_anonymous(vma)) {
> - _pmd = pmdp_huge_clear_flush_notify(vma, haddr, pmd);
> + old_pmd = pmdp_huge_clear_flush_notify(vma, haddr, pmd);
> /*
> * We are going to unmap this huge page. So
> * just go ahead and zap it
> @@ -2053,16 +2053,25 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
> zap_deposited_table(mm, pmd);
> if (vma_is_special_huge(vma))
> return;
> - page = pmd_page(_pmd);
> - if (!PageDirty(page) && pmd_dirty(_pmd))
> - set_page_dirty(page);
> - if (!PageReferenced(page) && pmd_young(_pmd))
> - SetPageReferenced(page);
> - page_remove_rmap(page, true);
> - put_page(page);
> + if (unlikely(is_pmd_migration_entry(old_pmd))) {
> + swp_entry_t entry;
> +
> + entry = pmd_to_swp_entry(old_pmd);
> + page = migration_entry_to_page(entry);
> + } else {
> + page = pmd_page(old_pmd);
> + if (!PageDirty(page) && pmd_dirty(old_pmd))
> + set_page_dirty(page);
> + if (!PageReferenced(page) && pmd_young(old_pmd))
> + SetPageReferenced(page);
> + page_remove_rmap(page, true);
> + put_page(page);
> + }
> add_mm_counter(mm, mm_counter_file(page), -HPAGE_PMD_NR);
> return;
> - } else if (pmd_trans_huge(*pmd) && is_huge_zero_pmd(*pmd)) {
> + }
> +
> + if (pmd_present(*pmd) && is_huge_zero_pmd(*pmd)) {
> /*
> * FIXME: Do we want to invalidate secondary mmu by calling
> * mmu_notifier_invalidate_range() see comments below inside
> @@ -2072,7 +2081,8 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
> * small page also write protected so it does not seems useful
> * to invalidate secondary mmu at this time.
> */
> - return __split_huge_zero_page_pmd(vma, haddr, pmd);
> + __split_huge_zero_page_pmd(vma, haddr, pmd);
> + return;
> }
>
> /*
> diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
> index c2210e1cdb51..4e640baf9794 100644
> --- a/mm/pgtable-generic.c
> +++ b/mm/pgtable-generic.c
> @@ -135,9 +135,8 @@ pmd_t pmdp_huge_clear_flush(struct vm_area_struct *vma, unsigned long address,
> {
> pmd_t pmd;
> VM_BUG_ON(address & ~HPAGE_PMD_MASK);
> - VM_BUG_ON(!pmd_present(*pmdp));
> - /* Below assumes pmd_present() is true */
> - VM_BUG_ON(!pmd_trans_huge(*pmdp) && !pmd_devmap(*pmdp));
> + VM_BUG_ON(pmd_present(*pmdp) && !pmd_trans_huge(*pmdp) &&
> + !pmd_devmap(*pmdp));
> pmd = pmdp_huge_get_and_clear(vma->vm_mm, address, pmdp);
> flush_pmd_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
> return pmd;
> --
> 2.32.0.rc0.204.g9fa02ecfa5-goog
>