linux-kernel - Re: [PATCH 11/28] mm, swap: clean up and consolidate helper for mTHP swapin check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGsJ_4wQBG+kNuqgWs5+V+pyJGGN3ok=fJd0caub18CiUSOLwg@mail.gmail.com>
Date: Mon, 19 May 2025 19:57:06 +0800
From: Barry Song <21cnbao@...il.com>
To: Kairui Song <ryncsn@...il.com>
Cc: akpm@...ux-foundation.org, baolin.wang@...ux.alibaba.com, bhe@...hat.com, 
	chrisl@...nel.org, david@...hat.com, hannes@...xchg.org, hughd@...gle.com, 
	kaleshsingh@...gle.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	nphamcs@...il.com, ryan.roberts@....com, shikemeng@...weicloud.com, 
	tim.c.chen@...ux.intel.com, willy@...radead.org, ying.huang@...ux.alibaba.com, 
	yosryahmed@...gle.com
Subject: Re: [PATCH 11/28] mm, swap: clean up and consolidate helper for mTHP
 swapin check

On Mon, May 19, 2025 at 7:10 PM Kairui Song <ryncsn@...il.com> wrote:
>
> On Mon, May 19, 2025 at 3:08 PM Barry Song <21cnbao@...il.com> wrote:
> >
> > > From: Kairui Song <kasong@...cent.com>
> >
> >
> > > -static bool can_swapin_thp(struct vm_fault *vmf, pte_t *ptep, int nr_pages)
> > > +static bool can_swapin_thp(struct vm_fault *vmf, pte_t *ptep,
> > > +                        unsigned long addr, unsigned int nr_pages)
> >
> > > +     if (unlikely(addr < max(addr & PMD_MASK, vmf->vma->vm_start) ||
> > > +                  addr_end > pmd_addr_end(addr, vmf->vma->vm_end)))
> >
> >
> > > @@ -4731,27 +4732,18 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> > >       page_idx = 0;
> > >       address = vmf->address;
> > >       ptep = vmf->pte;
> > > +
> > >       if (folio_test_large(folio) && folio_test_swapcache(folio)) {
> > > -             int nr = folio_nr_pages(folio);
> > > +             unsigned long nr = folio_nr_pages(folio);
> > >               unsigned long idx = folio_page_idx(folio, page);
> > > -             unsigned long folio_start = address - idx * PAGE_SIZE;
> > > -             unsigned long folio_end = folio_start + nr * PAGE_SIZE;
> > > -             pte_t *folio_ptep;
> > > -             pte_t folio_pte;
> > > +             unsigned long folio_address = address - idx * PAGE_SIZE;
> > > +             pte_t *folio_ptep = vmf->pte - idx;
> > >
> > > -             if (unlikely(folio_start < max(address & PMD_MASK, vma->vm_start)))
> > > -                     goto check_folio;
> >
> > We are handling a corner case a large folio is remapped to an unaligned address.
> > For example,
> >
> > A 64KiB mTHP at address:  XGB + 2MB +4KB,
> >
> > Its start address will be XGB + 2MB - 60KB which is another PMD.
> >
> > The previous code will return false; now your can_swapin_thp() will return true
> > as you are using XGB + 2MB - 60KB as the argument "addr" in can_swapin_thp().
>
> Thanks very much for the info and explanation.
>
> You are right, I need to keep using vmf->address in can_swapin_thp:
>
> if (unlikely(addr < max(vmf->address & PMD_MASK, vmf->vma->vm_start) ||
>      addr_end > pmd_addr_end(vmf->address, vmf->vma->vm_end)))
> return false;
>
> But one thing I'm not so sure is how that happens? And there isn't an
> address checking in the direct swapin mTHP check above?

In page faults, we always make the start address aligned with
PAGE_SIZE * nr_pages.
but for a mremap, we can't actually control the dst address.

so the original code can exclude this case for direct mTHP swapin by
the below you are
dropping:

- if (unlikely(folio_start < max(address & PMD_MASK, vma->vm_start)))
-               goto check_folio;
- if (unlikely(folio_end > pmd_addr_end(address, vma->vm_end)))
-               goto check_folio;

Thanks
Barry