[PATCH v6.18.y] selftests/mm: hugepage-mremap: fix mapping alignment

[PATCH v6.18.y] selftests/mm: hugepage-mremap: fix mapping alignment

[Luiz Capitulino]

When running the HugeTLB kselftest suite on arm64 with 64K base pages,
this test always fails:

  # -------------------------
  # running ./hugepage-mremap
  # -------------------------
  # TAP version 13
  # 1..1
  # # Map haddr: Returned address is 0x7eaa40000000
  # # Map daddr: Returned address is 0x7daa40000000
  # # Map vaddr: Returned address is 0x7faa40000000
  # Bail out! ioctl-UFFDIO_REGISTER: Invalid argument
  # # Planned tests != run tests (1 != 0)
  # # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
  # [FAIL]
  not ok 1 hugepage-mremap # exit=1
  # NOTE: These hugetlb tests provide minimal coverage.  Use
  #       https://github.com/libhugetlbfs/libhugetlbfs.git for
  #       hugetlb regression testing.
  # SKIP ./uffd-wp-mremap

The problem is that the default HugeTLB page size on such systems is
512 MiB and 'length' is not aligned to the page size. This causes
uffd_register() to fail as 'length' is 10 MiB and not aligned to the
HugeTLB page size.

On upstream this was fixed by a914785f6349 ("selftests/mm: hugetlb-mremap:
add setup of HugeTLB pages") as that commit aligns 'length' to the
default HugeTLB page size as part of what it's doing. Since this commit
is part of a 50+ patch series, we backport only the 'length' alignment
bits to fix the test.

Signed-off-by: Luiz Capitulino <luizcap@redhat.com>
---

Two notes:

 1. This is fixing an issue upstream commit a914785f6349
    incidently fixed
 2. This should apply to v6.12.y as well

 tools/testing/selftests/mm/hugepage-mremap.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/testing/selftests/mm/hugepage-mremap.c b/tools/testing/selftests/mm/hugepage-mremap.c
index 928c1045e295..0d4e1a5b185d 100644
--- a/tools/testing/selftests/mm/hugepage-mremap.c
+++ b/tools/testing/selftests/mm/hugepage-mremap.c
@@ -97,6 +97,7 @@ static void register_region_with_uffd(char *addr, size_t len)
 
 int main(int argc, char *argv[])
 {
+	unsigned long hugepage_size;
 	size_t length = 0;
 	int ret = 0, fd;
 
@@ -114,7 +115,12 @@ int main(int argc, char *argv[])
 	else
 		length = DEFAULT_LENGTH_MB;
 
+	hugepage_size = default_huge_page_size();
+	if (!hugepage_size)
+		ksft_exit_skip("Could not detect default hugetlb page size\n");
+
 	length = MB_TO_BYTES(length);
+	length = (length + hugepage_size - 1) & ~(hugepage_size - 1);
 	fd = memfd_create(argv[0], MFD_HUGETLB);
 	if (fd < 0)
 		ksft_exit_fail_msg("Open failed: %s\n", strerror(errno));
-- 
2.55.0

Re: [PATCH v6.18.y] selftests/mm: hugepage-mremap: fix mapping alignment

[Sasha Levin]

> On upstream this was fixed by a914785f6349 ("selftests/mm: hugetlb-mremap:
> add setup of HugeTLB pages") as that commit aligns 'length' to the
> default HugeTLB page size as part of what it's doing. Since this commit
> is part of a 50+ patch series, we backport only the 'length' alignment
> bits to fix the test.

The change itself looks good, but the commit message has no upstream
reference line. The SHA only appears in the prose and the subject differs
from upstream, so the backport can't be matched to the upstream commit.

Could you send a v2 with

  commit a914785f6349da754e1226420bf4e51961956769 upstream.

as the first line of the body, with your explanation of the partial
backport below it?

>  2. This should apply to v6.12.y as well

6.12 has the same failure, so please send the v2 for both 6.18.y and
6.12.y.

-- 
Thanks,
Sasha

Re: [PATCH v6.18.y] selftests/mm: hugepage-mremap: fix mapping alignment

[Luiz Capitulino]

On 9/26/26 11:26 AM, Sasha Levin wrote:
>> On upstream this was fixed by a914785f6349 ("selftests/mm: hugetlb-mremap:
>> add setup of HugeTLB pages") as that commit aligns 'length' to the
>> default HugeTLB page size as part of what it's doing. Since this commit
>> is part of a 50+ patch series, we backport only the 'length' alignment
>> bits to fix the test.
> 
> The change itself looks good, but the commit message has no upstream
> reference line. The SHA only appears in the prose and the subject differs
> from upstream, so the backport can't be matched to the upstream commit.
> 
> Could you send a v2 with
> 
>    commit a914785f6349da754e1226420bf4e51961956769 upstream.
> 
> as the first line of the body, with your explanation of the partial
> backport below it?

Yes, will do.

I was unsure if I should add it or not because this is not exactly a
backport, so I left it out. But I'm sending v2 with it now.

>>   2. This should apply to v6.12.y as well
> 
> 6.12 has the same failure, so please send the v2 for both 6.18.y and
> 6.12.y.

Will do.