Fix incorrect access of hugetlb pte entries

huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma).

The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned.

Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.

Fixes 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")

Cc [email protected]

Signed-off-by Dev Jain <[email protected]>

---
 arch/arm64/mm/hugetlbpage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/mm/hugetlbpage.c +0 -0

index 30772a909aea3..8e799c1fe0aa6 100644

try_to_unmap_one() handles hugetlb folios when memory failure needs to replace a poisoned hugetlb mapping with a hwpoison entry. In that case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get().

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Just use huge_ptep_get() for dereferencing a huge pte pointer.

Fixes c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")

Cc [email protected]

Reported-by David Hildenbrand <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
  include/linux/hugetlb.h |  3 +++
  mm/rmap.c               | 16 ++++++++++------
  2 files changed, 13 insertions(+), 6 deletions(-)

include/linux/hugetlb.h +0 -0

index 2abaf99321e90..fdb7bdf7645c5 100644

include/linux/hugetlb.h +0 -0

  static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
  					  unsigned long addr, pte_t *ptep)
  {

mm/rmap.c +10 -6

index 1c77d5dc06e9f..aa8a254efaecc 100644
@@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
  		/* Unexpected PMD-mapped THP? */
  		VM_BUG_ON_FOLIO(!pvmw.pte, folio);
 
-		/*
-		 * Handle PFN swap PTEs, such as device-exclusive ones, that
-		 * actually map pages.
-		 */
-		pteval = ptep_get(pvmw.pte);
+		address = pvmw.address;
+		if (folio_test_hugetlb(folio)) {
+			pteval = huge_ptep_get(mm, address, pvmw.pte);
+		} else {
+			/*
+			 * Handle PFN swap PTEs, such as device-exclusive ones,
+			 * that actually map pages.
+			 */
+			pteval = ptep_get(pvmw.pte);
+		}
  		if (likely(pte_present(pteval))) {
  			pfn = pte_pfn(pteval);
  		} else {

@@ -2110,7 +2115,6 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
  		}
 
  		subpage = folio_page(folio, pfn - folio_pfn(folio));
-		address = pvmw.address;
  		anon_exclusive = folio_test_anon(folio) &&
  				 PageAnonExclusive(subpage);
 

Quoted 27 lines · Dev Jain

try_to_unmap_one() handles hugetlb folios when memory failure needs to replace a poisoned hugetlb mapping with a hwpoison entry. In that case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get().

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Just use huge_ptep_get() for dereferencing a huge pte pointer.

Fixes c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")

Cc [email protected]

Reported-by David Hildenbrand <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
  include/linux/hugetlb.h |  3 +++
  mm/rmap.c               | 16 ++++++++++------

  2 files changed, 13 insertions(+), 6 deletions(-)

include/linux/hugetlb.h +0 -0

index 2abaf99321e90..fdb7bdf7645c5 100644

include/linux/hugetlb.h static inline void hugetlb_count_sub(long l, struct mm_struct *mm) · line 1265

Quoted 5 lines

include/linux/hugetlb.h +2 -0

@@ -1261,6 +1261,9 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
   {
   }
   +pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
+            pte_t *ptep);
+

Maybe I didn't express my thoughts clearly in the first version, let me explain in more detail.

We should define this stub as a no-op for !CONFIG_HUGETLB_PAGE (like set_huge_pte_at, that is why I mentioned 5d4af6195c87c6 for your reference in your previous version). Currently, you've added a declaration, but the function itself doesn't actually exist, which seems quite strange to me.

Muchun,
Thanks.

Quoted 35 lines

include/linux/hugetlb.h +0 -0

   static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
                         unsigned long addr, pte_t *ptep)
   {

mm/rmap.c +0 -0

index 1c77d5dc06e9f..aa8a254efaecc 100644
@@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
           /* Unexpected PMD-mapped THP? */
           VM_BUG_ON_FOLIO(!pvmw.pte, folio);

  -        /*
-         * Handle PFN swap PTEs, such as device-exclusive ones, that -         * actually map pages.
-         */
-        pteval = ptep_get(pvmw.pte);
+        address = pvmw.address;
+        if (folio_test_hugetlb(folio)) {
+            pteval = huge_ptep_get(mm, address, pvmw.pte); +        } else {
+            /*
+             * Handle PFN swap PTEs, such as device-exclusive ones, +             * that actually map pages.
+             */
+            pteval = ptep_get(pvmw.pte);
+        }
          if (likely(pte_present(pteval))) {
              pfn = pte_pfn(pteval);
          } else {

mm/rmap.c +0 -1

@@ -2110,7 +2115,6 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
           }
             subpage = folio_page(folio, pfn - folio_pfn(folio));
-        address = pvmw.address;

          anon_exclusive = folio_test_anon(folio) && PageAnonExclusive(subpage);

Quoted 39 lines · Muchun Song

Quoted 27 lines · Dev Jain

try_to_unmap_one() handles hugetlb folios when memory failure needs to replace a poisoned hugetlb mapping with a hwpoison entry. In that case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get().

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Just use huge_ptep_get() for dereferencing a huge pte pointer.

Fixes c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")

Cc [email protected]

Reported-by David Hildenbrand <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
  include/linux/hugetlb.h |  3 +++
  mm/rmap.c               | 16 ++++++++++------
  2 files changed, 13 insertions(+), 6 deletions(-)

include/linux/hugetlb.h +0 -0

index 2abaf99321e90..fdb7bdf7645c5 100644

include/linux/hugetlb.h static inline void hugetlb_count_sub(long l, struct mm_struct *mm) · line 1265

Quoted 5 lines

include/linux/hugetlb.h +2 -0

@@ -1261,6 +1261,9 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
  {
  }
  +pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
+            pte_t *ptep);
+

Maybe I didn't express my thoughts clearly in the first version, let me explain in more detail.

Quoted 4 lines

We should define this stub as a no-op for !CONFIG_HUGETLB_PAGE (like set_huge_pte_at, that is why I mentioned 5d4af6195c87c6 for your reference in your previous version). Currently, you've added a declaration, but the function itself doesn't actually exist, which seems quite strange to me.

https://lore.kernel.org/all/[email protected]/

David suggested this. Honestly I quite like David's suggestion, what do you think?

Quoted 39 lines

Muchun,
Thanks.

Quoted 34 lines

include/linux/hugetlb.h +0 -0

  static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
                        unsigned long addr, pte_t *ptep)
  {

mm/rmap.c +10 -5

index 1c77d5dc06e9f..aa8a254efaecc 100644
@@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
          /* Unexpected PMD-mapped THP? */
          VM_BUG_ON_FOLIO(!pvmw.pte, folio);
  -        /*
-         * Handle PFN swap PTEs, such as device-exclusive ones, that
-         * actually map pages.
-         */
-        pteval = ptep_get(pvmw.pte);
+        address = pvmw.address;
+        if (folio_test_hugetlb(folio)) {
+            pteval = huge_ptep_get(mm, address, pvmw.pte);
+        } else {
+            /*
+             * Handle PFN swap PTEs, such as device-exclusive ones,
+             * that actually map pages.
+             */
+            pteval = ptep_get(pvmw.pte);
+        }
          if (likely(pte_present(pteval))) {
              pfn = pte_pfn(pteval);
          } else {

@@ -2110,7 +2115,6 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
          }
            subpage = folio_page(folio, pfn - folio_pfn(folio));
-        address = pvmw.address;
          anon_exclusive = folio_test_anon(folio) &&
                   PageAnonExclusive(subpage);

Quoted 20 lines · Dev Jain

Quoted 10 lines · Muchun Song

Maybe I didn't express my thoughts clearly in the first version, let me explain in more detail.

We should define this stub as a no-op for !CONFIG_HUGETLB_PAGE (like set_huge_pte_at, that is why I mentioned 5d4af6195c87c6 for your reference in your previous version). Currently, you've added a declaration, but the function itself doesn't actually exist, which seems quite strange to me.

https://lore.kernel.org/all/[email protected]/

Quoted 2 lines

David suggested this. Honestly I quite like David's suggestion, what do you think?

Thanks for pointing that out, I missed it earlier. That said, looking at hugetlb.h, it already contains quite a few no-op stubs. To keep things consistent, I'd personally prefer a stub here. Since David suggested this, I’d love to hear his thoughts on this as well.

try_to_unmap_one() handles hugetlb folios when memory failure needs to replace a poisoned hugetlb mapping with a hwpoison entry. In that case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get().

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Just use huge_ptep_get() for dereferencing a huge pte pointer.

Fixes c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")

Cc [email protected]

Reported-by David Hildenbrand <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
 include/linux/hugetlb.h |  3 +++
 mm/rmap.c               | 16 ++++++++++------
 2 files changed, 13 insertions(+), 6 deletions(-)

include/linux/hugetlb.h +0 -0

index 2abaf99321e90..fdb7bdf7645c5 100644

include/linux/hugetlb.h +1 -0

+
 static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
 					  unsigned long addr, pte_t *ptep)
 {

mm/rmap.c +0 -0

index 1c77d5dc06e9f..aa8a254efaecc 100644

Quoted 27 lines · Dev Jain

try_to_unmap_one() handles hugetlb folios when memory failure needs to replace a poisoned hugetlb mapping with a hwpoison entry. In that case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get().

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Just use huge_ptep_get() for dereferencing a huge pte pointer.

Fixes c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")

Cc [email protected]

Reported-by David Hildenbrand <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
 include/linux/hugetlb.h |  3 +++
 mm/rmap.c               | 16 ++++++++++------
 2 files changed, 13 insertions(+), 6 deletions(-)

include/linux/hugetlb.h +0 -0

index 2abaf99321e90..fdb7bdf7645c5 100644

include/linux/hugetlb.h static inline void hugetlb_count_sub(long l, struct mm_struct *mm) · line 1265

Quoted 5 lines

include/linux/hugetlb.h +2 -0

@@ -1261,6 +1261,9 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
 {
 }
 
+pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
+		    pte_t *ptep);

Two tabs, or just in a single line.

If others prefer a stub, I don't care. This here is shortest to let the linker bail out.

Quoted 12 lines

include/linux/hugetlb.h +1 -0

+
 static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
 					  unsigned long addr, pte_t *ptep)
 {

mm/rmap.c +0 -0

index 1c77d5dc06e9f..aa8a254efaecc 100644
@@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
 		/* Unexpected PMD-mapped THP? */
 		VM_BUG_ON_FOLIO(!pvmw.pte, folio);
 

mm/rmap.c static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, · line 2101

Quoted 4 lines

mm/rmap.c +0 -4

-		/*
-		 * Handle PFN swap PTEs, such as device-exclusive ones, that
-		 * actually map pages.
-		 */

That comment now actually belongs above the pte_present() check below.

Quoted 9 lines

Quoted 9 lines

mm/rmap.c +0 -0

index 1c77d5dc06e9f..aa8a254efaecc 100644
@@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
 		/* Unexpected PMD-mapped THP? */
 		VM_BUG_ON_FOLIO(!pvmw.pte, folio);
 

Quoted 6 lines

mm/rmap.c static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, · line 2101

Quoted 4 lines

mm/rmap.c +0 -4

-		/*
-		 * Handle PFN swap PTEs, such as device-exclusive ones, that
-		 * actually map pages.
-		 */

That comment now actually belongs above the pte_present() check below.

Oops I mindlessly just copied the comment.

I will then rather put it in the else block which gets the pfn from the softleaf, that is the most appropriate.

try_to_migrate_one() is used by folio migration to replace a present mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads the huge pte entry with ptep_get().

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Use huge_ptep_get() to dereference a huge pte pointer.

Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into try_to_migrate_one.

Fixes a98a2f0c8ce1 ("mm/rmap: split migration into its own function")

Cc [email protected]

Acked-by Muchun Song <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
 mm/rmap.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

mm/rmap.c +0 -3

index aa8a254efaecc..abc3a44baaa3d 100644
@@ -2505,11 +2505,16 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
 		/* Unexpected PMD-mapped THP? */
 		VM_BUG_ON_FOLIO(!pvmw.pte, folio);
 
-		/*
-		 * Handle PFN swap PTEs, such as device-exclusive ones, that
-		 * actually map pages.

remove_migration_pte() converts migration entries back to present PTEs after folio migration completes. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get().

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

check_pte() is the final validation step in page_vma_mapped_walk(). It reads pvmw->pte with ptep_get() to decide whether the entry maps the PFN range being walked. For hugetlb VMAs, that pointer refers to a hugetlb entry.

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Use huge_ptep_get() to dereference a huge pte pointer.

Fixes ace71a19cec5 ("mm: introduce page_vma_mapped_walk()")

Cc [email protected]

Signed-off-by Dev Jain <[email protected]>

check_pte() is the final validation step in page_vma_mapped_walk(). It reads pvmw->pte with ptep_get() to decide whether the entry maps the PFN range being walked. For hugetlb VMAs, that pointer refers to a hugetlb entry.

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Use huge_ptep_get() to dereference a huge pte pointer.

Fixes ace71a19cec5 ("mm: introduce page_vma_mapped_walk()")

Cc [email protected]

Signed-off-by Dev Jain <[email protected]>

---

prot_none_hugetlb_entry() is the hugetlb callback for the early mprotect(PROT_NONE) PFN permission walk on x86.

The callback passes the decoded PFN to pfn_modify_allowed(). For a hugetlb callback, the pte pointer refers to a hugetlb entry. On architectures where hugetlb entries need huge_ptep_get(), reading that entry with ptep_get() can make the permission check use the wrong PFN.

Use huge_ptep_get() before decoding the hugetlb PFN.

Currently there is no path which can trigger a bug: huge_ptep_get() is a simple ptep_get() for x86, and the prot_none walk occurs only for x86.

So no need to backport - use the correct helper anyways.

Fixes 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")

Signed-off-by Dev Jain <[email protected]>

---

 mm/mprotect.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

mm/mprotect.c +7 -1

index 9cbf932b028cf..23779632d18bf 100644
@@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
 		0 : -EACCES;
 }
 
+#ifdef CONFIG_HUGETLB_PAGE
 static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
 				   unsigned long addr, unsigned long next,
 				   struct mm_walk *walk)
 {
-	return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
+	pte_t entry = huge_ptep_get(walk->mm, addr, pte);
+
+	return pfn_modify_allowed(pte_pfn(entry),
 				  *(pgprot_t *)(walk->private)) ?
 		0 : -EACCES;
 }
+#else
+#define prot_none_hugetlb_entry	NULL
+#endif
 
 static int prot_none_test(unsigned long addr, unsigned long next,
 			  struct mm_walk *walk)

Quoted 15 lines · Dev Jain

prot_none_hugetlb_entry() is the hugetlb callback for the early mprotect(PROT_NONE) PFN permission walk on x86.

The callback passes the decoded PFN to pfn_modify_allowed(). For a hugetlb callback, the pte pointer refers to a hugetlb entry. On architectures where hugetlb entries need huge_ptep_get(), reading that entry with ptep_get() can make the permission check use the wrong PFN.

Use huge_ptep_get() before decoding the hugetlb PFN.

Currently there is no path which can trigger a bug: huge_ptep_get() is a simple ptep_get() for x86, and the prot_none walk occurs only for x86.

So no need to backport - use the correct helper anyways.

Quoted 3 lines

Fixes 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")

Signed-off-by Dev Jain <[email protected]>

---

@Muchun, I did not do the change you suggested: if we do #ifdef around the hugetlb callback, then for CONFIG_HUGETLB_PAGE=n, prot_none_hugetlb_entry() is defined but not used, giving compile error.

prot_none_hugetlb_entry() is the hugetlb callback for the early mprotect(PROT_NONE) PFN permission walk on x86.

The callback passes the decoded PFN to pfn_modify_allowed(). For a hugetlb callback, the pte pointer refers to a hugetlb entry. On architectures where hugetlb entries need huge_ptep_get(), reading that entry with ptep_get() can make the permission check use the wrong PFN.

Use huge_ptep_get() before decoding the hugetlb PFN.

Currently there is no path which can trigger a bug: huge_ptep_get() is a simple ptep_get() for x86, and the prot_none walk occurs only for x86.

So no need to backport - use the correct helper anyways.

Fixes 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")

Signed-off-by Dev Jain <[email protected]>

prot_none_hugetlb_entry() is the hugetlb callback for the early mprotect(PROT_NONE) PFN permission walk on x86.

The callback passes the decoded PFN to pfn_modify_allowed(). For a hugetlb callback, the pte pointer refers to a hugetlb entry. On architectures where hugetlb entries need huge_ptep_get(), reading that entry with ptep_get() can make the permission check use the wrong PFN.

Use huge_ptep_get() before decoding the hugetlb PFN.

Currently there is no path which can trigger a bug: huge_ptep_get() is a simple ptep_get() for x86, and the prot_none walk occurs only for x86.

So no need to backport - use the correct helper anyways.

Fixes 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")

Signed-off-by Dev Jain <[email protected]>

---
 mm/mprotect.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

mm/mprotect.c +0 -0

index 9cbf932b028cf..23779632d18bf 100644

Quoted 26 lines · Dev Jain

prot_none_hugetlb_entry() is the hugetlb callback for the early mprotect(PROT_NONE) PFN permission walk on x86.

The callback passes the decoded PFN to pfn_modify_allowed(). For a hugetlb callback, the pte pointer refers to a hugetlb entry. On architectures where hugetlb entries need huge_ptep_get(), reading that entry with ptep_get() can make the permission check use the wrong PFN.

Use huge_ptep_get() before decoding the hugetlb PFN.

Currently there is no path which can trigger a bug: huge_ptep_get() is a simple ptep_get() for x86, and the prot_none walk occurs only for x86.

So no need to backport - use the correct helper anyways.

Fixes 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")

Signed-off-by Dev Jain <[email protected]>

---
 mm/mprotect.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

mm/mprotect.c +0 -0

index 9cbf932b028cf..23779632d18bf 100644

mm/mprotect.c static int prot_none_pte_entry(pte_t *pte, unsigned long addr, · line 707

Quoted 10 lines

mm/mprotect.c +2 -1

@@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
 		0 : -EACCES;
 }
 
+#ifdef CONFIG_HUGETLB_PAGE
 static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
 				   unsigned long addr, unsigned long next,
 				   struct mm_walk *walk)
 {
-	return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
+	pte_t entry = huge_ptep_get(walk->mm, addr, pte);

Nit: can be const :)

mm/mprotect.c static int prot_none_pte_entry(pte_t *pte, unsigned long addr, · line 711

Quoted 4 lines

mm/mprotect.c +2 -0

+
+	return pfn_modify_allowed(pte_pfn(entry),
 				  *(pgprot_t *)(walk->private)) ?
 		0 : -EACCES;

Indentation is odd.

Can we just make this readable?

if (pfn_modify_allowed ...)
return 0
return -EACCESS;