This seems to be a bug not by any report but by code observations. When GUP sees a devpmd or devpud, it should return whatever value returned from follow_devmap_p[mu]d(). If page==NULL returned, it means a fault is probably required. Skipping return the NULL should allow the code to fall through, which can cause unexpected behavior. It was there at least before the follow page rework (080dbb618b) in 2017, so 6 years. Not yet digging for a Fixes, assuming it can hardly trigger even if the logical bug does exist. Signed-off-by: Peter Xu <peterx@xxxxxxxxxx> --- mm/gup.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/mm/gup.c b/mm/gup.c index a8b73a8289ad..0e00204761d2 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -708,8 +708,7 @@ static struct page *follow_pmd_mask(struct vm_area_struct *vma, ptl = pmd_lock(mm, pmd); page = follow_devmap_pmd(vma, address, pmd, flags, &ctx->pgmap); spin_unlock(ptl); - if (page) - return page; + return page; } if (likely(!pmd_trans_huge(pmdval))) return follow_page_pte(vma, address, pmd, flags, &ctx->pgmap); @@ -756,8 +755,7 @@ static struct page *follow_pud_mask(struct vm_area_struct *vma, ptl = pud_lock(mm, pud); page = follow_devmap_pud(vma, address, pud, flags, &ctx->pgmap); spin_unlock(ptl); - if (page) - return page; + return page; } if (unlikely(pud_bad(*pud))) return no_page_table(vma, flags); -- 2.41.0
