Re: [PATCH 2/2] selftests/mm: add hugetlb_region_cache_race regression test

[Muchun Song <muchun.song@linux.dev>]

> On Jul 14, 2026, at 01:14, Xiangfeng Cai <caixiangfeng@bytedance.com> wrote:
> 
> Add a regression test for the list corruption in
> allocate_file_region_entries() fixed by the previous patch
> ("mm/hugetlb: fix list corruption in allocate_file_region_entries()").
> 
> Triggering the bug requires a concurrent reservation operation to drain
> resv->region_cache while allocate_file_region_entries() has dropped
> resv->lock for its GFP_KERNEL allocation, forcing its retry loop to run
> again.  As the mmap() and fallocate(PUNCH_HOLE) paths serialise on
> inode_lock, the cache has to be drained by faults from a separate address
> space.  The test forks several processes sharing one hugetlb inode via
> memfd_create(MFD_HUGETLB); each mmap()s and faults ranges and punches holes
> to keep the shared resv_map fragmented.
> 
> Two modes are provided:
> 
> - default: a safe single-process functional check that exercises the buggy
>   line without forcing a second loop iteration; safe on any kernel.
> 
> - --trigger: the concurrent reproducer, which panics a vulnerable
>   CONFIG_DEBUG_LIST=y kernel and is therefore opt-in.  It faults pages in,
>   so it needs as many free huge pages as the file is large.
> 
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Xiangfeng Cai <caixiangfeng@bytedance.com>

It looks like this is a regression test case for a very specific instance of
list corruption.

In my opinion, selftests should focus more on functional testing with clear
expected behaviors and results to users. I don't think it's worth maintaining
a test case for a minor issue like this, especially since code changes happen
so quickly. Once the code evolves, this specific list corruption might never
occur again, and the function itself could even be deleted during a refactor.

Therefore, I wouldn't recommend adding this as a selftest.

Thanks.