Skip to content

Commit 5b99241

Browse files
committed
Revert "vfio/type1: Unpin zero pages"
This reverts commit 873aefb. This was a heinous workaround and it turns out it's been fixed in mm twice since it was introduced. Most recently, commit c8070b7 ("mm: Don't pin ZERO_PAGE in pin_user_pages()") would have prevented running up the zeropage refcount, but even before that commit 84209e8 ("mm/gup: reliable R/O long-term pinning in COW mappings") avoids the vfio use case from pinning the zeropage at all, instead replacing it with exclusive anonymous pages. Remove this now useless overhead. Suggested-by: David Hildenbrand <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]>
1 parent 81617c1 commit 5b99241

File tree

1 file changed

+0
-12
lines changed

1 file changed

+0
-12
lines changed

drivers/vfio/vfio_iommu_type1.c

Lines changed: 0 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -567,18 +567,6 @@ static int vaddr_get_pfns(struct mm_struct *mm, unsigned long vaddr,
567567
ret = pin_user_pages_remote(mm, vaddr, npages, flags | FOLL_LONGTERM,
568568
pages, NULL);
569569
if (ret > 0) {
570-
int i;
571-
572-
/*
573-
* The zero page is always resident, we don't need to pin it
574-
* and it falls into our invalid/reserved test so we don't
575-
* unpin in put_pfn(). Unpin all zero pages in the batch here.
576-
*/
577-
for (i = 0 ; i < ret; i++) {
578-
if (unlikely(is_zero_pfn(page_to_pfn(pages[i]))))
579-
unpin_user_page(pages[i]);
580-
}
581-
582570
*pfn = page_to_pfn(pages[0]);
583571
goto done;
584572
}

0 commit comments

Comments
 (0)