| 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
| ||
|
Message-ID: <8a26ae97-9a78-4db5-be98-9c1f6e4fb403@lucifer.local>
Date: Fri, 29 Aug 2025 16:19:49 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, Alexander Potapenko <glider@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Brendan Jackman <jackmanb@...gle.com>,
Christoph Lameter <cl@...two.org>, Dennis Zhou <dennis@...nel.org>,
Dmitry Vyukov <dvyukov@...gle.com>, dri-devel@...ts.freedesktop.org,
intel-gfx@...ts.freedesktop.org, iommu@...ts.linux.dev,
io-uring@...r.kernel.org, Jason Gunthorpe <jgg@...dia.com>,
Jens Axboe <axboe@...nel.dk>, Johannes Weiner <hannes@...xchg.org>,
John Hubbard <jhubbard@...dia.com>, kasan-dev@...glegroups.com,
kvm@...r.kernel.org, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-arm-kernel@...s.com, linux-arm-kernel@...ts.infradead.org,
linux-crypto@...r.kernel.org, linux-ide@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-mips@...r.kernel.org,
linux-mmc@...r.kernel.org, linux-mm@...ck.org,
linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
linux-scsi@...r.kernel.org, Marco Elver <elver@...gle.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Michal Hocko <mhocko@...e.com>, Mike Rapoport <rppt@...nel.org>,
Muchun Song <muchun.song@...ux.dev>, netdev@...r.kernel.org,
Oscar Salvador <osalvador@...e.de>, Peter Xu <peterx@...hat.com>,
Robin Murphy <robin.murphy@....com>,
Suren Baghdasaryan <surenb@...gle.com>, Tejun Heo <tj@...nel.org>,
virtualization@...ts.linux.dev, Vlastimil Babka <vbabka@...e.cz>,
wireguard@...ts.zx2c4.com, x86@...nel.org, Zi Yan <ziy@...dia.com>
Subject: Re: [PATCH v1 18/36] mm/gup: drop nth_page() usage within folio when
recording subpages
On Fri, Aug 29, 2025 at 03:41:40PM +0200, David Hildenbrand wrote:
> On 28.08.25 18:37, Lorenzo Stoakes wrote:
> > On Thu, Aug 28, 2025 at 12:01:22AM +0200, David Hildenbrand wrote:
> > > nth_page() is no longer required when iterating over pages within a
> > > single folio, so let's just drop it when recording subpages.
> > >
> > > Signed-off-by: David Hildenbrand <david@...hat.com>
> >
> > This looks correct to me, so notwithtsanding suggestion below, LGTM and:
> >
> > Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> >
> > > ---
> > > mm/gup.c | 7 +++----
> > > 1 file changed, 3 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/mm/gup.c b/mm/gup.c
> > > index b2a78f0291273..89ca0813791ab 100644
> > > --- a/mm/gup.c
> > > +++ b/mm/gup.c
> > > @@ -488,12 +488,11 @@ static int record_subpages(struct page *page, unsigned long sz,
> > > unsigned long addr, unsigned long end,
> > > struct page **pages)
> > > {
> > > - struct page *start_page;
> > > int nr;
> > >
> > > - start_page = nth_page(page, (addr & (sz - 1)) >> PAGE_SHIFT);
> > > + page += (addr & (sz - 1)) >> PAGE_SHIFT;
> > > for (nr = 0; addr != end; nr++, addr += PAGE_SIZE)
> > > - pages[nr] = nth_page(start_page, nr);
> > > + pages[nr] = page++;
> >
> >
> > This is really nice, but I wonder if (while we're here) we can't be even
> > more clear as to what's going on here, e.g.:
> >
> > static int record_subpages(struct page *page, unsigned long sz,
> > unsigned long addr, unsigned long end,
> > struct page **pages)
> > {
> > size_t offset_in_folio = (addr & (sz - 1)) >> PAGE_SHIFT;
> > struct page *subpage = page + offset_in_folio;
> >
> > for (; addr != end; addr += PAGE_SIZE)
> > *pages++ = subpage++;
> >
> > return nr;
> > }
> >
> > Or some variant of that with the masking stuff self-documented.
>
> What about the following cleanup on top:
>
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 89ca0813791ab..5a72a135ec70b 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -484,19 +484,6 @@ static inline void mm_set_has_pinned_flag(struct mm_struct *mm)
> #ifdef CONFIG_MMU
> #ifdef CONFIG_HAVE_GUP_FAST
> -static int record_subpages(struct page *page, unsigned long sz,
> - unsigned long addr, unsigned long end,
> - struct page **pages)
> -{
> - int nr;
> -
> - page += (addr & (sz - 1)) >> PAGE_SHIFT;
> - for (nr = 0; addr != end; nr++, addr += PAGE_SIZE)
> - pages[nr] = page++;
> -
> - return nr;
> -}
> -
> /**
> * try_grab_folio_fast() - Attempt to get or pin a folio in fast path.
> * @page: pointer to page to be grabbed
> @@ -2963,8 +2950,8 @@ static int gup_fast_pmd_leaf(pmd_t orig, pmd_t *pmdp, unsigned long addr,
> if (pmd_special(orig))
> return 0;
> - page = pmd_page(orig);
> - refs = record_subpages(page, PMD_SIZE, addr, end, pages + *nr);
> + refs = (end - addr) >> PAGE_SHIFT;
> + page = pmd_page(orig) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
Ah I see we use page_folio() in try_grab_folio_fast() so this being within PMD is ok.
> folio = try_grab_folio_fast(page, refs, flags);
> if (!folio)
> @@ -2985,6 +2972,8 @@ static int gup_fast_pmd_leaf(pmd_t orig, pmd_t *pmdp, unsigned long addr,
> }
> *nr += refs;
> + for (; refs; refs--)
> + *(pages++) = page++;
> folio_set_referenced(folio);
> return 1;
> }
> @@ -3003,8 +2992,8 @@ static int gup_fast_pud_leaf(pud_t orig, pud_t *pudp, unsigned long addr,
> if (pud_special(orig))
> return 0;
> - page = pud_page(orig);
> - refs = record_subpages(page, PUD_SIZE, addr, end, pages + *nr);
> + refs = (end - addr) >> PAGE_SHIFT;
> + page = pud_page(orig) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
> folio = try_grab_folio_fast(page, refs, flags);
> if (!folio)
> @@ -3026,6 +3015,8 @@ static int gup_fast_pud_leaf(pud_t orig, pud_t *pudp, unsigned long addr,
> }
> *nr += refs;
> + for (; refs; refs--)
> + *(pages++) = page++;
> folio_set_referenced(folio);
> return 1;
> }
>
>
> The nice thing is that we only record pages in the array if they actually passed our tests.
Yeah that's nice actually.
This is fine (not the meme :P)
So yes let's do this!
>
>
> --
> Cheers
>
> David / dhildenb
>
Cheers, Lorenzo
Powered by blists - more mailing lists