[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26a7803a-bf20-c60b-459d-2c8f82f2f4f6@huawei.com>
Date: Mon, 9 Feb 2026 20:01:36 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Jiaqi Yan <jiaqiyan@...gle.com>
CC: <nao.horiguchi@...il.com>, <tony.luck@...el.com>,
<wangkefeng.wang@...wei.com>, <willy@...radead.org>,
<akpm@...ux-foundation.org>, <osalvador@...e.de>, <rientjes@...gle.com>,
<duenwen@...gle.com>, <jthoughton@...gle.com>, <jgg@...dia.com>,
<ankita@...dia.com>, <peterx@...hat.com>, <sidhartha.kumar@...cle.com>,
<ziy@...dia.com>, <david@...hat.com>, <dave.hansen@...ux.intel.com>,
<muchun.song@...ux.dev>, <linux-mm@...ck.org>,
<linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
<william.roche@...cle.com>, <harry.yoo@...cle.com>, <jane.chu@...cle.com>
Subject: Re: [PATCH v3 2/3] selftests/mm: test userspace MFR for HugeTLB
hugepage
On 2026/2/4 3: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.
>
> Reviewed-by: Jane Chu <jane.chu@...cle.com>
> Signed-off-by: Jiaqi Yan <jiaqiyan@...gle.com>
It's not required but could this testcase be written into the tools/testing/selftests/mm/memory-failure.c [1]?
[1] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-unstable&id=cf2929c618fec0a22702b3abd0778bbdde6e458e
Thanks.
.
Powered by blists - more mailing lists