[PATCH RFC 05/12] mm/gup: Fix follow_devmap_p[mu]d() to return even if NULL

[Peter Xu <peterx@redhat.com>]

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@redhat.com>
---
 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