[PATCH 0/2] Minor fixups for hugetlb fault path

[PATCH 0/2] Minor fixups for hugetlb fault path

[Oscar Salvador]

Hi,

this series contains a couple of fixups for hugetlb_fault and hugetlb_wp
respectively, where a VM_FAULT_SET_HINDEX call was missing.

I did not bother with a Fixes tag because the missing piece here is that
we will not report to userspace the right extension of the faulty area
by adjusting struct kernel_siginfo.si_addr_lsb, but I do not consider that
to be a big issue because I assume that userspace already knows the size
of the mapping anyway.

Oscar Salvador (2):
  mm/hugetlb: Add missing VM_FAULT_SET_HINDEX in hugetlb_fault
  mm/hugetlb: Add missing VM_FAULT_SET_HINDEX in hugetlb_wp

 mm/hugetlb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-- 
2.44.0

[PATCH 1/2] mm/hugetlb: Add missing VM_FAULT_SET_HINDEX in hugetlb_fault

[Oscar Salvador]

commit af19487f00f3 ("mm: make PTE_MARKER_SWAPIN_ERROR more general") added
the code to handle pte_markers in hugetlb faulting path.
In case of an UFFD_POISON event, a PTE_MARKER_POISONED will be created and
we will return VM_FAULT_HWPOISON_LARGE upon detecting that in the fault path.
Add the missing VM_FAULT_SET_HINDEX, so the right si_addr_lsb will be passed
to userspace to report the extension of the faulty area.

Signed-off-by: Oscar Salvador <osalvador@suse.de>
---
 mm/hugetlb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 33d175add044..262456daf327 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6485,7 +6485,8 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
 				pte_marker_get(pte_to_swp_entry(vmf.orig_pte));
 
 			if (marker & PTE_MARKER_POISONED) {
-				ret = VM_FAULT_HWPOISON_LARGE;
+				ret = VM_FAULT_HWPOISON_LARGE |
+				      VM_FAULT_SET_HINDEX(hstate_index(h));
 				goto out_mutex;
 			}
 		}
-- 
2.44.0

[PATCH 2/2] mm/hugetlb: Add missing VM_FAULT_SET_HINDEX in hugetlb_wp

[Oscar Salvador]

commit 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage
copy-on-write faults") added support to use the mc variants when
coping hugetlb pages on CoW faults.
Add the missing VM_FAULT_SET_HINDEX, so the right si_addr_lsb will be
passed to userspace to report the extension of the faulty area.

Signed-off-by: Oscar Salvador <osalvador@suse.de>
---
 mm/hugetlb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 262456daf327..6be78e7d4f6e 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6067,7 +6067,7 @@ static vm_fault_t hugetlb_wp(struct folio *pagecache_folio,
 		goto out_release_all;
 
 	if (copy_user_large_folio(new_folio, old_folio, vmf->real_address, vma)) {
-		ret = VM_FAULT_HWPOISON_LARGE;
+		ret = VM_FAULT_HWPOISON_LARGE | VM_FAULT_SET_HINDEX(hstate_index(h));
 		goto out_release_all;
 	}
 	__folio_mark_uptodate(new_folio);
-- 
2.44.0

Re: [PATCH 0/2] Minor fixups for hugetlb fault path

[Peter Xu]

On Thu, May 09, 2024 at 12:01:46PM +0200, Oscar Salvador wrote:
> Hi,
> 
> this series contains a couple of fixups for hugetlb_fault and hugetlb_wp
> respectively, where a VM_FAULT_SET_HINDEX call was missing.
> 
> I did not bother with a Fixes tag because the missing piece here is that
> we will not report to userspace the right extension of the faulty area
> by adjusting struct kernel_siginfo.si_addr_lsb, but I do not consider that
> to be a big issue because I assume that userspace already knows the size
> of the mapping anyway.

Acked-by: Peter Xu <peterx@redhat.com>

-- 
Peter Xu

Re: [PATCH 0/2] Minor fixups for hugetlb fault path

[Axel Rasmussen]

On Thu, May 9, 2024 at 6:26 AM Peter Xu <peterx@redhat.com> wrote:
>
> On Thu, May 09, 2024 at 12:01:46PM +0200, Oscar Salvador wrote:
> > Hi,
> >
> > this series contains a couple of fixups for hugetlb_fault and hugetlb_wp
> > respectively, where a VM_FAULT_SET_HINDEX call was missing.
> >
> > I did not bother with a Fixes tag because the missing piece here is that
> > we will not report to userspace the right extension of the faulty area
> > by adjusting struct kernel_siginfo.si_addr_lsb, but I do not consider that
> > to be a big issue because I assume that userspace already knows the size
> > of the mapping anyway.
>
> Acked-by: Peter Xu <peterx@redhat.com>

Looks correct to me as well. Thanks!

Acked-by: Axel Rasmussen <axelrasmussen@google.com>

>
> --
> Peter Xu
>