| Message ID | 20240327152332.950956-7-peterx@redhat.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere, archived |
| Headers | show |
| Series | mm/gup: Unify hugetlb, part 2 | expand |
On 27.03.24 16:23, peterx@redhat.com wrote: > From: Peter Xu <peterx@redhat.com> > > Hugepd format for GUP is only used in PowerPC with hugetlbfs. There are > some kernel usage of hugepd (can refer to hugepd_populate_kernel() for > PPC_8XX), however those pages are not candidates for GUP. > > Commit a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to > file-backed mappings") added a check to fail gup-fast if there's potential > risk of violating GUP over writeback file systems. That should never apply > to hugepd. Considering that hugepd is an old format (and even > software-only), there's no plan to extend hugepd into other file typed > memories that is prone to the same issue. > > Drop that check, not only because it'll never be true for hugepd per any > known plan, but also it paves way for reusing the function outside > fast-gup. > > To make sure we'll still remember this issue just in case hugepd will be > extended to support non-hugetlbfs memories, add a rich comment above > gup_huge_pd(), explaining the issue with proper references. > > Cc: Christoph Hellwig <hch@infradead.org> > Cc: Lorenzo Stoakes <lstoakes@gmail.com> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Peter Xu <peterx@redhat.com> > --- @Andrew, you properly adjusted the code to remove the gup_fast_folio_allowed() call instead of the folio_fast_pin_allowed() call, but (1) the commit subject (2) comment for gup_huge_pd() Still mention folio_fast_pin_allowed(). The patch "mm/gup: handle hugepd for follow_page()" then moves that (outdated) comment.
On Thu, 28 Mar 2024 11:10:59 +0100 David Hildenbrand <david@redhat.com> wrote: > @Andrew, you properly adjusted the code to remove the > gup_fast_folio_allowed() call instead of the folio_fast_pin_allowed() > call, but > > (1) the commit subject > (2) comment for gup_huge_pd() > > Still mention folio_fast_pin_allowed(). > > The patch "mm/gup: handle hugepd for follow_page()" then moves that > (outdated) comment. OK, thanks, I fixed all that up.
diff --git a/mm/gup.c b/mm/gup.c index e7510b6ce765..db35b056fc9a 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -2832,11 +2832,6 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned long addr, return 0; } - if (!folio_fast_pin_allowed(folio, flags)) { - gup_put_folio(folio, refs, flags); - return 0; - } - if (!pte_write(pte) && gup_must_unshare(NULL, flags, &folio->page)) { gup_put_folio(folio, refs, flags); return 0; @@ -2847,6 +2842,14 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned long addr, return 1; } +/* + * NOTE: currently GUP for a hugepd is only possible on hugetlbfs file + * systems on Power, which does not have issue with folio writeback against + * GUP updates. When hugepd will be extended to support non-hugetlbfs or + * even anonymous memory, we need to do extra check as what we do with most + * of the other folios. See writable_file_mapping_allowed() and + * folio_fast_pin_allowed() for more information. + */ static int gup_huge_pd(hugepd_t hugepd, unsigned long addr, unsigned int pdshift, unsigned long end, unsigned int flags, struct page **pages, int *nr)