Re: [PATCH v3 2/3] selftests/mm: test userspace MFR for HugeTLB hugepage

[Jiaqi Yan <jiaqiyan@google.com>]

On Wed, Feb 4, 2026 at 9:53 AM William Roche <william.roche@oracle.com> wrote:
>
>
> On 2/3/26 20:23, Jiaqi Yan wrote:
> > Test the userspace memory failure recovery (MFR) policy for HugeTLB:
> >
> > 1. Create a memfd backed by HugeTLB and had MFD_MF_KEEP_UE_MAPPED set.
> >
> > 2. Allocate and map 4 hugepages to the process.
> >
> > 3. Create sub-threads to MADV_HWPOISON inner addresses of the 1st hugepage.
> >
> > 4. Check if the process gets correct SIGBUS for each poisoned raw page.
> >
> > 5. Check if all memory are still accessible and content valid.
> >
> > 6. Check if the poisoned hugepage is dealt with after memfd released.
> >
> > Two configurables in the test:
> >
> > - hugepage_size: size of the hugepage, 1G or 2M.
> >
> > - nr_hwp_pages: number of pages within the 1st hugepage to MADV_HWPOISON.
> In this version, you are introducing this new test argument
> "nr_hwp_pages" to indicate how many of the pre-defined offsets we want
> to poison inside the hugepage (between 1 and 8).
> But is there any advantage to give the choice to the user instead of
> testing them all ?

Yeah, nr_hwp_pages doesn't seem very useful. It was useful when I want
the test to run in two modes: single page vs multple pages. Let me
just make the test to testing 8 pages.

>
> As a suggestion, should we have this test program setting or verifying
> the minimal number of hugepages of the right type, instead of relying on
> the user to set them manually ?

Yeah, I agree, we can just run for 2 different hugepagesize.

> And at the end, should we try to unpoison the impacted pages ? So that
> the lab machine where the tests run can continue to use all its memory ?

Good point, we can include this as a test cleanup step.

>
> Thanks for your feedback,
> William.
>