kselftest: mm: fix some failure of split_huge_page_test

There're some random failure for split_huge_page_test when khugepaged collapses pages into pmd again which had split by the test.

Prevent the khugepaged's collapses for split page by setting the mapped pmd-huge-page with MADV_NOHUGEPAGE before split.

Suggested-by Kevin Brodsky <[email protected]>

Suggested-by Lorenzo Stoakes (ARM) <[email protected]>

Reviewed-by Lorenzo Stoakes (ARM) <[email protected]>

Reviewed-by Zi Yan <[email protected]>

Signed-off-by Yeoreum Yun <[email protected]>

---

Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on AArch64”), glibc may call madvise(MADV_HUGEPAGE) for sufficiently large allocations made by memalign().

The underlying VMA may start at a different address from the aligned address returned by memalign(). Furthermore, a subsequent madvise(MADV_HUGEPAGE) call does not split the VMA because the flag is already set.

This causes split_huge_page_test to fail because the check_huge_xxx() helpers incorrectly require the address returned by memalign() to match the VMA start address reported in /proc/self/smaps.

Instead of relying on /proc/self/smaps, use /proc/self/pagemap and /proc/kpageflags to detect huge-page mappings and large folios:

1. If hpage_size == pmd_pagesize, check PAGE_IS_HUGE instead of using check_large_folios(), since only the mapping type matters. This identifies PMD-mapped huge pages.
2. Otherwise, use check_large_folios() to detect large folios. This covers mTHP cases.
3. Check the folio flags according to the type of huge page.

Suggested-by David Hildenbrand (Arm) <[email protected]>

Suggested-by Zi Yan <[email protected]>

Reviewed-by Zi Yan <[email protected]>

Reviewed-by Baolin Wang <[email protected]>

Tested-by Baolin Wang <[email protected]>

Acked-by Lorenzo Stoakes (ARM) <[email protected]>

Signed-off-by Yeoreum Yun <[email protected]>

---
 tools/testing/selftests/mm/vm_util.c | 145 ++++++++++++++++++++++-------------
 tools/testing/selftests/mm/vm_util.h |   1 +
 2 files changed, 92 insertions(+), 54 deletions(-)

tools/testing/selftests/mm/vm_util.c +0 -0

index 4821a3563036..dc62ce84e143 100644

tools/testing/selftests/mm/vm_util.c +4 -2

-	if (hpage_size == pmd_pagesize)
-		return __check_pmd_huge(addr, "AnonHugePages: ", nr_hpages, hpage_size);
+static bool check_huge_type(uint64_t categories, uint64_t kpageflags,
+			    enum check_huge_type type)
+{
+	const bool file = categories & PAGE_IS_FILE;

tools/testing/selftests/mm/vm_util.c +16 -5

-	return check_large_folios(addr, len, nr_hpages, hpage_size);
+	return false;
 }
 
-bool check_huge_file(void *addr, size_t len, int nr_hpages, uint64_t hpage_size)
+static bool __check_huge(void *addr, size_t len, int nr_hpages,
+			 uint64_t hpage_size, enum check_huge_type type)
 {
-	uint64_t pmd_pagesize = read_pmd_pagesize();
+	bool ret = false;
+	int pagemap_fd, kpageflags_fd;
+	int nr_pmd_mappings = 0;
+	uint64_t pmd_pagesize, scan_mapping_size;
+	uint64_t categories, kpf;
+	unsigned long pfn;
+	bool check_pmd_mapping, allow_nonpresent;
+	char *start = addr;
+	char *end = start + len;
 
+	pmd_pagesize = read_pmd_pagesize();
 	if (!pmd_pagesize)
 		ksft_exit_fail_msg("reading PMD pagesize failed\n");
 
-	if (hpage_size == pmd_pagesize)
-		return __check_pmd_huge(addr, "FilePmdMapped:", nr_hpages, hpage_size);
+	check_pmd_mapping = (hpage_size == pmd_pagesize);
+	scan_mapping_size = (nr_hpages > 0) ? hpage_size : psize();
+	/* Some mTHP tests check a partially populated PMD-sized range. */

tools/testing/selftests/mm/vm_util.c +35 -0

+		ksft_exit_fail_msg("open kpageflags fail\n");
+	}
+
+	if (!check_pmd_mapping &&
+	    !check_large_folios(pagemap_fd, kpageflags_fd,
+				addr, len, nr_hpages, hpage_size))
+		goto out;
+
+	for (; start < end; start += scan_mapping_size) {
+		categories = pagemap_scan_get_categories(pagemap_fd, start);
+		pfn = pagemap_get_pfn(pagemap_fd, start);
+		if (pfn == -1UL) {
+			if (!allow_nonpresent)
+				goto out;
+			else
+				continue;
+		}
+		if (pageflags_get(pfn, kpageflags_fd, &kpf))
+			ksft_exit_fail_msg("read kpageflags: %s\n", strerror(errno));
+		if (check_pmd_mapping && (categories & PAGE_IS_HUGE))
+			nr_pmd_mappings++;
+		if (kpf & KPF_COMPOUND_TAIL)
+			continue;
+		if (!check_huge_type(categories, kpf, type))
+			goto out;
+	}
+
+	if (check_pmd_mapping && (nr_pmd_mappings != nr_hpages))
+		goto out;
+	ret = true;
+
+out:
+	close(pagemap_fd);
+	close(kpageflags_fd);
+	return ret;
 }

Quoted 37 lines

Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on AArch64”), glibc may call madvise(MADV_HUGEPAGE) for sufficiently large allocations made by memalign().

The underlying VMA may start at a different address from the aligned address returned by memalign(). Furthermore, a subsequent madvise(MADV_HUGEPAGE) call does not split the VMA because the flag is already set.

This causes split_huge_page_test to fail because the check_huge_xxx() helpers incorrectly require the address returned by memalign() to match the VMA start address reported in /proc/self/smaps.

Instead of relying on /proc/self/smaps, use /proc/self/pagemap and /proc/kpageflags to detect huge-page mappings and large folios:

1. If hpage_size == pmd_pagesize, check PAGE_IS_HUGE instead of using check_large_folios(), since only the mapping type matters. This identifies PMD-mapped huge pages.
2. Otherwise, use check_large_folios() to detect large folios. This covers mTHP cases.
3. Check the folio flags according to the type of huge page.

Suggested-by David Hildenbrand (Arm) <[email protected]>

Suggested-by Zi Yan <[email protected]>

Reviewed-by Zi Yan <[email protected]>

Reviewed-by Baolin Wang <[email protected]>

Tested-by Baolin Wang <[email protected]>

Acked-by Lorenzo Stoakes (ARM) <[email protected]>

Signed-off-by Yeoreum Yun <[email protected]>

---
 tools/testing/selftests/mm/vm_util.c | 145 ++++++++++++++++++++++-------------
 tools/testing/selftests/mm/vm_util.h |   1 +
 2 files changed, 92 insertions(+), 54 deletions(-)

tools/testing/selftests/mm/vm_util.c +0 -0

index 4821a3563036..dc62ce84e143 100644

[...]

Quoted 7 lines

tools/testing/selftests/mm/vm_util.c +4 -2

-	if (hpage_size == pmd_pagesize)
-		return __check_pmd_huge(addr, "AnonHugePages: ", nr_hpages, hpage_size);
+static bool check_huge_type(uint64_t categories, uint64_t kpageflags,
+			    enum check_huge_type type)
+{
+	const bool file = categories & PAGE_IS_FILE;

tools/testing/selftests/mm/vm_util.c static bool check_large_folios(void *addr, size_t len, int nr_hpages, · line 403

Quoted 10 lines

tools/testing/selftests/mm/vm_util.c +10 -0

+	const bool swapbacked = kpageflags & KPF_SWAPBACKED;
+
+	switch (type) {
+	case CHECK_HUGE_ANON:
+		return !file;
+	case CHECK_HUGE_FILE:
+		return file && !swapbacked;
+	case CHECK_HUGE_SHMEM:
+		return file & swapbacked;
+	}

Why do we even need CHECK_HUGE_SHMEM?

That's really just a legacy thing for using smaps to identify huge pages.

It's sufficient to identify CHECK_HUGE_FILE if you know that you have shmem mapping.

You will not arbitrarily have non-shmem folios in a shmem mapping :)

Quoted 32 lines

tools/testing/selftests/mm/vm_util.c +17 -5

-	return check_large_folios(addr, len, nr_hpages, hpage_size);
+	return false;
 }
 
-bool check_huge_file(void *addr, size_t len, int nr_hpages, uint64_t hpage_size)
+static bool __check_huge(void *addr, size_t len, int nr_hpages,
+			 uint64_t hpage_size, enum check_huge_type type)
 {
-	uint64_t pmd_pagesize = read_pmd_pagesize();
+	bool ret = false;
+	int pagemap_fd, kpageflags_fd;
+	int nr_pmd_mappings = 0;
+	uint64_t pmd_pagesize, scan_mapping_size;
+	uint64_t categories, kpf;
+	unsigned long pfn;
+	bool check_pmd_mapping, allow_nonpresent;
+	char *start = addr;
+	char *end = start + len;
 
+	pmd_pagesize = read_pmd_pagesize();
 	if (!pmd_pagesize)
 		ksft_exit_fail_msg("reading PMD pagesize failed\n");
 
-	if (hpage_size == pmd_pagesize)
-		return __check_pmd_huge(addr, "FilePmdMapped:", nr_hpages, hpage_size);
+	check_pmd_mapping = (hpage_size == pmd_pagesize);
+	scan_mapping_size = (nr_hpages > 0) ? hpage_size : psize();
+	/* Some mTHP tests check a partially populated PMD-sized range. */
+	allow_nonpresent = (uint64_t)nr_hpages * hpage_size < len;

tools/testing/selftests/mm/vm_util.c static bool check_large_folios(void *addr, size_t len, int nr_hpages, · line 436

Quoted 8 lines

tools/testing/selftests/mm/vm_util.c +7 -1

-	return check_large_folios(addr, len, nr_hpages, hpage_size);
+	pagemap_fd = open(PAGEMAP_PATH, O_RDONLY);
+	if (pagemap_fd < 0)
+		ksft_exit_fail_msg("open pagemap fail\n");
+
+	kpageflags_fd = open(KPAGEFLAGS_PATH, O_RDONLY);
+	if (kpageflags_fd < 0) {
+		close(pagemap_fd);

No need to cleanup when exiting.

Quoted 37 lines

tools/testing/selftests/mm/vm_util.c +35 -0

+		ksft_exit_fail_msg("open kpageflags fail\n");
+	}
+
+	if (!check_pmd_mapping &&
+	    !check_large_folios(pagemap_fd, kpageflags_fd,
+				addr, len, nr_hpages, hpage_size))
+		goto out;
+
+	for (; start < end; start += scan_mapping_size) {
+		categories = pagemap_scan_get_categories(pagemap_fd, start);
+		pfn = pagemap_get_pfn(pagemap_fd, start);
+		if (pfn == -1UL) {
+			if (!allow_nonpresent)
+				goto out;
+			else
+				continue;
+		}
+		if (pageflags_get(pfn, kpageflags_fd, &kpf))
+			ksft_exit_fail_msg("read kpageflags: %s\n", strerror(errno));
+		if (check_pmd_mapping && (categories & PAGE_IS_HUGE))
+			nr_pmd_mappings++;
+		if (kpf & KPF_COMPOUND_TAIL)
+			continue;
+		if (!check_huge_type(categories, kpf, type))
+			goto out;
+	}
+
+	if (check_pmd_mapping && (nr_pmd_mappings != nr_hpages))
+		goto out;
+	ret = true;
+
+out:
+	close(pagemap_fd);
+	close(kpageflags_fd);
+	return ret;
 }

Signature · 3 lines

Cheers,

David

Quoted 63 lines · Yeoreum Yun

Quoted 37 lines

Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on AArch64”), glibc may call madvise(MADV_HUGEPAGE) for sufficiently large allocations made by memalign().

The underlying VMA may start at a different address from the aligned address returned by memalign(). Furthermore, a subsequent madvise(MADV_HUGEPAGE) call does not split the VMA because the flag is already set.

This causes split_huge_page_test to fail because the check_huge_xxx() helpers incorrectly require the address returned by memalign() to match the VMA start address reported in /proc/self/smaps.

Instead of relying on /proc/self/smaps, use /proc/self/pagemap and /proc/kpageflags to detect huge-page mappings and large folios:

1. If hpage_size == pmd_pagesize, check PAGE_IS_HUGE instead of using check_large_folios(), since only the mapping type matters. This identifies PMD-mapped huge pages.
2. Otherwise, use check_large_folios() to detect large folios. This covers mTHP cases.
3. Check the folio flags according to the type of huge page.

Suggested-by David Hildenbrand (Arm) <[email protected]>

Suggested-by Zi Yan <[email protected]>

Reviewed-by Zi Yan <[email protected]>

Reviewed-by Baolin Wang <[email protected]>

Tested-by Baolin Wang <[email protected]>

Acked-by Lorenzo Stoakes (ARM) <[email protected]>

Signed-off-by Yeoreum Yun <[email protected]>

---
 tools/testing/selftests/mm/vm_util.c | 145 ++++++++++++++++++++++-------------
 tools/testing/selftests/mm/vm_util.h |   1 +
 2 files changed, 92 insertions(+), 54 deletions(-)

tools/testing/selftests/mm/vm_util.c +0 -0

index 4821a3563036..dc62ce84e143 100644

[...]

Quoted 7 lines

tools/testing/selftests/mm/vm_util.c +4 -2

-	if (hpage_size == pmd_pagesize)
-		return __check_pmd_huge(addr, "AnonHugePages: ", nr_hpages, hpage_size);
+static bool check_huge_type(uint64_t categories, uint64_t kpageflags,
+			    enum check_huge_type type)
+{
+	const bool file = categories & PAGE_IS_FILE;

tools/testing/selftests/mm/vm_util.c static bool check_large_folios(void *addr, size_t len, int nr_hpages, · line 403

Quoted 10 lines

tools/testing/selftests/mm/vm_util.c +10 -0

+	const bool swapbacked = kpageflags & KPF_SWAPBACKED;
+
+	switch (type) {
+	case CHECK_HUGE_ANON:
+		return !file;
+	case CHECK_HUGE_FILE:
+		return file && !swapbacked;
+	case CHECK_HUGE_SHMEM:
+		return file & swapbacked;
+	}

Why do we even need CHECK_HUGE_SHMEM?

That's really just a legacy thing for using smaps to identify huge pages.

Quoted 3 lines

It's sufficient to identify CHECK_HUGE_FILE if you know that you have shmem mapping.

You will not arbitrarily have non-shmem folios in a shmem mapping :)

Agree. but there seems the case where discern whethr the mapping is with regular file or shmem like tmpfs -- khugepaged test where using __shmem_ops. So I think it would be better to keep this as-is.

Quoted 63 lines

Quoted 63 lines · Yeoreum Yun

Quoted 37 lines

Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on AArch64”), glibc may call madvise(MADV_HUGEPAGE) for sufficiently large allocations made by memalign().

The underlying VMA may start at a different address from the aligned address returned by memalign(). Furthermore, a subsequent madvise(MADV_HUGEPAGE) call does not split the VMA because the flag is already set.

This causes split_huge_page_test to fail because the check_huge_xxx() helpers incorrectly require the address returned by memalign() to match the VMA start address reported in /proc/self/smaps.

Instead of relying on /proc/self/smaps, use /proc/self/pagemap and /proc/kpageflags to detect huge-page mappings and large folios:

1. If hpage_size == pmd_pagesize, check PAGE_IS_HUGE instead of using check_large_folios(), since only the mapping type matters. This identifies PMD-mapped huge pages.
2. Otherwise, use check_large_folios() to detect large folios. This covers mTHP cases.
3. Check the folio flags according to the type of huge page.

Suggested-by David Hildenbrand (Arm) <[email protected]>

Suggested-by Zi Yan <[email protected]>

Reviewed-by Zi Yan <[email protected]>

Reviewed-by Baolin Wang <[email protected]>

Tested-by Baolin Wang <[email protected]>

Acked-by Lorenzo Stoakes (ARM) <[email protected]>

Signed-off-by Yeoreum Yun <[email protected]>

---
 tools/testing/selftests/mm/vm_util.c | 145 ++++++++++++++++++++++-------------
 tools/testing/selftests/mm/vm_util.h |   1 +
 2 files changed, 92 insertions(+), 54 deletions(-)

tools/testing/selftests/mm/vm_util.c +0 -0

index 4821a3563036..dc62ce84e143 100644

[...]

Quoted 7 lines

tools/testing/selftests/mm/vm_util.c +4 -2

-	if (hpage_size == pmd_pagesize)
-		return __check_pmd_huge(addr, "AnonHugePages: ", nr_hpages, hpage_size);
+static bool check_huge_type(uint64_t categories, uint64_t kpageflags,
+			    enum check_huge_type type)
+{
+	const bool file = categories & PAGE_IS_FILE;

tools/testing/selftests/mm/vm_util.c static bool check_large_folios(void *addr, size_t len, int nr_hpages, · line 403

Quoted 10 lines

tools/testing/selftests/mm/vm_util.c +10 -0

+	const bool swapbacked = kpageflags & KPF_SWAPBACKED;
+
+	switch (type) {
+	case CHECK_HUGE_ANON:
+		return !file;
+	case CHECK_HUGE_FILE:
+		return file && !swapbacked;
+	case CHECK_HUGE_SHMEM:
+		return file & swapbacked;
+	}

Why do we even need CHECK_HUGE_SHMEM?

That's really just a legacy thing for using smaps to identify huge pages.

Quoted 7 lines

Quoted 3 lines

It's sufficient to identify CHECK_HUGE_FILE if you know that you have shmem mapping.

You will not arbitrarily have non-shmem folios in a shmem mapping :)

Agree. but there seems the case where discern whethr the mapping is with regular file or shmem like tmpfs -- khugepaged test where using __shmem_ops. So I think it would be better to keep this as-is.

Let's not add or maintain unnecessary complexity.

hmem_check_huge can really just become check_huge_file.

Even file_check_huge can just be simplified.

There must be a pretty good reason why we'd want to keep this.

Quoted 8 lines · Yeoreum Yun

Quoted 4 lines

Agree. but there seems the case where discern whethr the mapping is with regular file or shmem like tmpfs -- khugepaged test where using __shmem_ops. So I think it would be better to keep this as-is.

Let's not add or maintain unnecessary complexity.

Quoted 5 lines

hmem_check_huge can really just become check_huge_file.

Even file_check_huge can just be simplified.

There must be a pretty good reason why we'd want to keep this.

Okay. then I'll change the check_huge_shmem() to check_huge_file() with the separate patch.

Quoted 12 lines · Yeoreum Yun

Quoted 12 lines · Yeoreum Yun

Quoted 4 lines

Agree. but there seems the case where discern whethr the mapping is with regular file or shmem like tmpfs -- khugepaged test where using __shmem_ops. So I think it would be better to keep this as-is.

Let's not add or maintain unnecessary complexity.

hmem_check_huge can really just become check_huge_file.

Even file_check_huge can just be simplified.

Quoted 4 lines

Quoted 1 line

There must be a pretty good reason why we'd want to keep this.

Okay. then I'll change the check_huge_shmem() to check_huge_file() with the separate patch.

You'll likely have to make both behave the same under the hood first to then remove check_huge_shmem().

tools/testing/selftests/mm/soft-dirty.c +2 -2

index 5f278913c4d7..b6fad38c8bee 100644
@@ -92,9 +92,9 @@ static void test_hugepage(int pagemap_fd, int pagesize)
 	if (!hpage_len)
 		ksft_exit_fail_msg("Reading PMD pagesize failed");
 
-	map = memalign(hpage_len, hpage_len);
+	map = alloc_isolated_mem(hpage_len, hpage_len);
 	if (!map)
-		ksft_exit_fail_msg("memalign failed\n");
+		ksft_exit_fail_msg("alloc_isolated_mem failed\n");
 
 	ret = madvise(map, hpage_len, MADV_HUGEPAGE);
 	if (ret)

Quoted 17 lines

tools/testing/selftests/mm/soft-dirty.c +2 -2

index 5f278913c4d7..b6fad38c8bee 100644
@@ -92,9 +92,9 @@ static void test_hugepage(int pagemap_fd, int pagesize)
 	if (!hpage_len)
 		ksft_exit_fail_msg("Reading PMD pagesize failed");
 
-	map = memalign(hpage_len, hpage_len);
+	map = alloc_isolated_mem(hpage_len, hpage_len);
 	if (!map)
-		ksft_exit_fail_msg("memalign failed\n");
+		ksft_exit_fail_msg("alloc_isolated_mem failed\n");
 
 	ret = madvise(map, hpage_len, MADV_HUGEPAGE);
 	if (ret)

tools/testing/selftests/mm/soft-dirty.c static void test_hugepage(int pagemap_fd, int pagesize) · line 134

Quoted 6 lines

tools/testing/selftests/mm/soft-dirty.c +1 -1

@@ -130,7 +130,7 @@ static void test_hugepage(int pagemap_fd, int pagesize)
 		ksft_test_result_skip("Test %s huge page allocation\n", __func__);
 		ksft_test_result_skip("Test %s huge page dirty bit\n", __func__);
 	}
-	free(map);
+	free_isolated_mem(map, hpage_len);
 }

smaps is really only problematic with merged VMAs when relying on exact page statistics. For other properties (vm flags, MMUPageSize) it's not a problem as long as our smap search just finds the VMA that covers an address.

Assuming we fixed check_huge_anon() to not use smaps, why is this change here required?

Quoted 28 lines

Quoted 17 lines

tools/testing/selftests/mm/soft-dirty.c +2 -2

index 5f278913c4d7..b6fad38c8bee 100644
@@ -92,9 +92,9 @@ static void test_hugepage(int pagemap_fd, int pagesize)
 	if (!hpage_len)
 		ksft_exit_fail_msg("Reading PMD pagesize failed");
 
-	map = memalign(hpage_len, hpage_len);
+	map = alloc_isolated_mem(hpage_len, hpage_len);
 	if (!map)
-		ksft_exit_fail_msg("memalign failed\n");
+		ksft_exit_fail_msg("alloc_isolated_mem failed\n");
 
 	ret = madvise(map, hpage_len, MADV_HUGEPAGE);
 	if (ret)

tools/testing/selftests/mm/soft-dirty.c static void test_hugepage(int pagemap_fd, int pagesize) · line 134

Quoted 6 lines

tools/testing/selftests/mm/soft-dirty.c +1 -1

@@ -130,7 +130,7 @@ static void test_hugepage(int pagemap_fd, int pagesize)
 		ksft_test_result_skip("Test %s huge page allocation\n", __func__);
 		ksft_test_result_skip("Test %s huge page dirty bit\n", __func__);
 	}
-	free(map);
+	free_isolated_mem(map, hpage_len);
 }

smaps is really only problematic with merged VMAs when relying on exact page statistics. For other properties (vm flags, MMUPageSize) it's not a problem as long as our smap search just finds the VMA that covers an address.

Quoted 2 lines

Assuming we fixed check_huge_anon() to not use smaps, why is this change here required?

Since there is no interface to get vm_flags not via /proc/self/smaps, It might be good to have it for preventing unwanted VMA merge.

And might be useful for future to prevent unwated VMA merge.

Quoted 28 lines · Yeoreum Yun

Quoted 28 lines

Quoted 17 lines

tools/testing/selftests/mm/soft-dirty.c +2 -2

index 5f278913c4d7..b6fad38c8bee 100644
@@ -92,9 +92,9 @@ static void test_hugepage(int pagemap_fd, int pagesize)
 	if (!hpage_len)
 		ksft_exit_fail_msg("Reading PMD pagesize failed");
 
-	map = memalign(hpage_len, hpage_len);
+	map = alloc_isolated_mem(hpage_len, hpage_len);
 	if (!map)
-		ksft_exit_fail_msg("memalign failed\n");
+		ksft_exit_fail_msg("alloc_isolated_mem failed\n");
 
 	ret = madvise(map, hpage_len, MADV_HUGEPAGE);
 	if (ret)

tools/testing/selftests/mm/soft-dirty.c static void test_hugepage(int pagemap_fd, int pagesize) · line 134

Quoted 6 lines

tools/testing/selftests/mm/soft-dirty.c +1 -1

@@ -130,7 +130,7 @@ static void test_hugepage(int pagemap_fd, int pagesize)
 		ksft_test_result_skip("Test %s huge page allocation\n", __func__);
 		ksft_test_result_skip("Test %s huge page dirty bit\n", __func__);
 	}
-	free(map);
+	free_isolated_mem(map, hpage_len);
 }

smaps is really only problematic with merged VMAs when relying on exact page statistics. For other properties (vm flags, MMUPageSize) it's not a problem as long as our smap search just finds the VMA that covers an address.

Quoted 7 lines

Quoted 2 lines

Assuming we fixed check_huge_anon() to not use smaps, why is this change here required?

Since there is no interface to get vm_flags not via /proc/self/smaps, It might be good to have it for preventing unwanted VMA merge.

And might be useful for future to prevent unwated VMA merge.

See my reply on why vm flags are generally not a problem. Just like other properties that are not changed during VMA merging.

Let's not perform random code changes without a clear picture.

And just to emphasize again: VMA merging could already be a problem before memalign() internal changes.

(also observe here how we do a MADV_HUGEPAGE, so this is all rather arbitrary, which is not good)

Quoted 10 lines · David Hildenbrand (Arm)

Quoted 5 lines · Yeoreum Yun

Since there is no interface to get vm_flags not via /proc/self/smaps, It might be good to have it for preventing unwanted VMA merge.

And might be useful for future to prevent unwated VMA merge.

See my reply on why vm flags are generally not a problem. Just like other properties that are not changed during VMA merging.

Quoted 7 lines

Let's not perform random code changes without a clear picture.

And just to emphasize again: VMA merging could already be a problem before memalign() internal changes.

(also observe here how we do a MADV_HUGEPAGE, so this is all rather arbitrary, which is not good)

As I mentioned in my previous reply, what I’m trying to prevent here is a failure when checking, immediately after memory allocation, that a specific vm_flag is not set.

Yes, I agree that this could have been a problem even before the internal changes to memalign(). An unwanted VMA merge could already occur at the time of memory allocation.

So what I’m trying to avoid is a test failure where, due to such an unexpected VMA merge during allocation, the subsequent check that a specific vm_flag is not present fails.

Quoted 23 lines · David Hildenbrand (Arm)

Quoted 10 lines · Yeoreum Yun

Quoted 5 lines

Since there is no interface to get vm_flags not via /proc/self/smaps, It might be good to have it for preventing unwanted VMA merge.

And might be useful for future to prevent unwated VMA merge.

See my reply on why vm flags are generally not a problem. Just like other properties that are not changed during VMA merging.

Quoted 7 lines

Let's not perform random code changes without a clear picture.

And just to emphasize again: VMA merging could already be a problem before memalign() internal changes.

(also observe here how we do a MADV_HUGEPAGE, so this is all rather arbitrary, which is not good)

As I mentioned in my previous reply, what I’m trying to prevent here is a failure when checking, immediately after memory allocation, that a specific vm_flag is not set.

Quoted 7 lines

Yes, I agree that this could have been a problem even before the internal changes to memalign(). An unwanted VMA merge could already occur at the time of memory allocation.

So what I’m trying to avoid is a test failure where, due to such an unexpected VMA merge during allocation, the subsequent check that a specific vm_flag is not present fails.

Which is only a guard-region marker problem?

Quoted 13 lines · Yeoreum Yun

Quoted 12 lines

As I mentioned in my previous reply, what I’m trying to prevent here is a failure when checking, immediately after memory allocation, that a specific vm_flag is not set.

Yes, I agree that this could have been a problem even before the internal changes to memalign(). An unwanted VMA merge could already occur at the time of memory allocation.

So what I’m trying to avoid is a test failure where, due to such an unexpected VMA merge during allocation, the subsequent check that a specific vm_flag is not present fails.

Quoted 1 line

Which is only a guard-region marker problem?

Yes. so if we remove ASSERT_FALSE(check_vmflag_guard(ptr)), TBH we don't need this patch unless other usage comes up to prevent unwanted VMA merge.

Would it be better to drop ASSERT_FALSE(check_vmflag_guard(ptr)) in guard test?

Quoted 13 lines

Quoted 13 lines · Yeoreum Yun

Quoted 12 lines

As I mentioned in my previous reply, what I’m trying to prevent here is a failure when checking, immediately after memory allocation, that a specific vm_flag is not set.

Yes, I agree that this could have been a problem even before the internal changes to memalign(). An unwanted VMA merge could already occur at the time of memory allocation.

So what I’m trying to avoid is a test failure where, due to such an unexpected VMA merge during allocation, the subsequent check that a specific vm_flag is not present fails.

Quoted 8 lines

Quoted 1 line

Which is only a guard-region marker problem?

Yes. so if we remove ASSERT_FALSE(check_vmflag_guard(ptr)), TBH we don't need this patch unless other usage comes up to prevent unwanted VMA merge.

Would it be better to drop ASSERT_FALSE(check_vmflag_guard(ptr)) in guard test?

I guess there is value in asserting that not all VMAs by accident start with an over-indication of maybe having guard pages, which is why Lorenzo added that check :)

But I think even alloc_isolated_mem() is wrong in that regard: if the original VMA gets merged, we could inherit the guard-marker, no?

Maybe the following would be good enough?

tools/testing/selftests/mm/guard-regions.c +12 -2

index 5c8ec3ca75d7d..791bf6a68b9e6 100644
@@ -2257,10 +2257,20 @@ TEST_F(guard_regions, smaps)
        char *ptr, *ptr2;
        int i;
 
-       /* Map a region. */
-       ptr = mmap_(self, variant, NULL, 10 * page_size, PROT_READ | PROT_WRITE, 0, 0);
+       /* Reserve a 10 page region with 1 page space to both sides. */
+       ptr = mmap_(self, variant, NULL, 12 * page_size, PROT_NONE, 0, 0);
        ASSERT_NE(ptr, MAP_FAILED);
 
+       /* Map a new region that is guaranteed to not get merged in any way. */
+       ptr = mmap_(self, variant | MAP_FIXED, ptr + pagesize, 10 * page_size,
+                   PROT_READ | PROT_WRITE, 0, 0);
+       ASSERT_EQ(ptr, ptr + pagesize);
+
+       /* Clean up the excess pages left and right. */
+       munmap(ptr, pagesize);
+       munmap(ptr + 11, pagesize);
+       ptr + = pagesize;
+
        /* We shouldn't yet see a guard flag. */
        ASSERT_FALSE(check_vmflag_guard(ptr));
 

Signature · 1 line

Cheers,

Quoted 23 lines · Yeoreum Yun

Quoted 13 lines

Quoted 13 lines · Yeoreum Yun

Quoted 12 lines

As I mentioned in my previous reply, what I’m trying to prevent here is a failure when checking, immediately after memory allocation, that a specific vm_flag is not set.

Yes, I agree that this could have been a problem even before the internal changes to memalign(). An unwanted VMA merge could already occur at the time of memory allocation.

So what I’m trying to avoid is a test failure where, due to such an unexpected VMA merge during allocation, the subsequent check that a specific vm_flag is not present fails.

Quoted 8 lines

Quoted 1 line

Which is only a guard-region marker problem?

Yes. so if we remove ASSERT_FALSE(check_vmflag_guard(ptr)), TBH we don't need this patch unless other usage comes up to prevent unwanted VMA merge.

Would it be better to drop ASSERT_FALSE(check_vmflag_guard(ptr)) in guard test?

Quoted 6 lines

I guess there is value in asserting that not all VMAs by accident start with an over-indication of maybe having guard pages, which is why Lorenzo added that check :)

But I think even alloc_isolated_mem() is wrong in that regard: if the original VMA gets merged, we could inherit the guard-marker, no?

True. I overlooked guard bit is sticky.

Quoted 30 lines

Maybe the following would be good enough?

tools/testing/selftests/mm/guard-regions.c +12 -2

index 5c8ec3ca75d7d..791bf6a68b9e6 100644
@@ -2257,10 +2257,20 @@ TEST_F(guard_regions, smaps)
        char *ptr, *ptr2;
        int i;
 
-       /* Map a region. */
-       ptr = mmap_(self, variant, NULL, 10 * page_size, PROT_READ | PROT_WRITE, 0, 0);
+       /* Reserve a 10 page region with 1 page space to both sides. */
+       ptr = mmap_(self, variant, NULL, 12 * page_size, PROT_NONE, 0, 0);
        ASSERT_NE(ptr, MAP_FAILED);
 
+       /* Map a new region that is guaranteed to not get merged in any way. */
+       ptr = mmap_(self, variant | MAP_FIXED, ptr + pagesize, 10 * page_size,
+                   PROT_READ | PROT_WRITE, 0, 0);
+       ASSERT_EQ(ptr, ptr + pagesize);
+
+       /* Clean up the excess pages left and right. */
+       munmap(ptr, pagesize);
+       munmap(ptr + 11, pagesize);
+       ptr + = pagesize;
+
        /* We shouldn't yet see a guard flag. */
        ASSERT_FALSE(check_vmflag_guard(ptr));
 

Quoted 2 lines

Signature · 1 line

Cheers,

It's enough but alloc_isolated_mem() could be modified to allocate with PROT_NONE first and then change the prot.

Quoted 9 lines · Yeoreum Yun

Quoted 7 lines

Yes. so if we remove ASSERT_FALSE(check_vmflag_guard(ptr)), TBH we don't need this patch unless other usage comes up to prevent unwanted VMA merge.

Would it be better to drop ASSERT_FALSE(check_vmflag_guard(ptr)) in guard test?

Quoted 6 lines

I guess there is value in asserting that not all VMAs by accident start with an over-indication of maybe having guard pages, which is why Lorenzo added that check :)

But I think even alloc_isolated_mem() is wrong in that regard: if the original VMA gets merged, we could inherit the guard-marker, no?

True. I overlooked guard bit is sticky.

Quoted 32 lines

Maybe the following would be good enough?

tools/testing/selftests/mm/guard-regions.c +12 -2

index 5c8ec3ca75d7d..791bf6a68b9e6 100644
@@ -2257,10 +2257,20 @@ TEST_F(guard_regions, smaps)
        char *ptr, *ptr2;
        int i;
 
-       /* Map a region. */
-       ptr = mmap_(self, variant, NULL, 10 * page_size, PROT_READ | PROT_WRITE, 0, 0);
+       /* Reserve a 10 page region with 1 page space to both sides. */
+       ptr = mmap_(self, variant, NULL, 12 * page_size, PROT_NONE, 0, 0);
        ASSERT_NE(ptr, MAP_FAILED);
 
+       /* Map a new region that is guaranteed to not get merged in any way. */
+       ptr = mmap_(self, variant | MAP_FIXED, ptr + pagesize, 10 * page_size,
+                   PROT_READ | PROT_WRITE, 0, 0);
+       ASSERT_EQ(ptr, ptr + pagesize);
+
+       /* Clean up the excess pages left and right. */
+       munmap(ptr, pagesize);
+       munmap(ptr + 11, pagesize);
+       ptr + = pagesize;
+
        /* We shouldn't yet see a guard flag. */
        ASSERT_FALSE(check_vmflag_guard(ptr));
 

Signature · 1 line

Cheers,

It's enough but alloc_isolated_mem() could be modified to allocate with PROT_NONE first and then change the prot.

It seems whether make a helper or testcase should write the code properly in case of unwanted VMA merge.

IMHO, instead of testcase write them all

Quoted 54 lines · Yeoreum Yun

Quoted 9 lines · Yeoreum Yun

Quoted 7 lines

Yes. so if we remove ASSERT_FALSE(check_vmflag_guard(ptr)), TBH we don't need this patch unless other usage comes up to prevent unwanted VMA merge.

Would it be better to drop ASSERT_FALSE(check_vmflag_guard(ptr)) in guard test?

Quoted 6 lines

I guess there is value in asserting that not all VMAs by accident start with an over-indication of maybe having guard pages, which is why Lorenzo added that check :)

But I think even alloc_isolated_mem() is wrong in that regard: if the original VMA gets merged, we could inherit the guard-marker, no?

True. I overlooked guard bit is sticky.

Quoted 32 lines

Maybe the following would be good enough?

tools/testing/selftests/mm/guard-regions.c +12 -2

index 5c8ec3ca75d7d..791bf6a68b9e6 100644
@@ -2257,10 +2257,20 @@ TEST_F(guard_regions, smaps)
        char *ptr, *ptr2;
        int i;
 
-       /* Map a region. */
-       ptr = mmap_(self, variant, NULL, 10 * page_size, PROT_READ | PROT_WRITE, 0, 0);
+       /* Reserve a 10 page region with 1 page space to both sides. */
+       ptr = mmap_(self, variant, NULL, 12 * page_size, PROT_NONE, 0, 0);
        ASSERT_NE(ptr, MAP_FAILED);
 
+       /* Map a new region that is guaranteed to not get merged in any way. */
+       ptr = mmap_(self, variant | MAP_FIXED, ptr + pagesize, 10 * page_size,
+                   PROT_READ | PROT_WRITE, 0, 0);
+       ASSERT_EQ(ptr, ptr + pagesize);
+
+       /* Clean up the excess pages left and right. */
+       munmap(ptr, pagesize);
+       munmap(ptr + 11, pagesize);
+       ptr + = pagesize;
+
        /* We shouldn't yet see a guard flag. */
        ASSERT_FALSE(check_vmflag_guard(ptr));
 

Signature · 1 line

Cheers,

It's enough but alloc_isolated_mem() could be modified to allocate with PROT_NONE first and then change the prot.

Quoted 4 lines

It seems whether make a helper or testcase should write the code properly in case of unwanted VMA merge.

IMHO, instead of testcase write them all

So far I am aware of exactly one test case, which others do absolutely need this?

Quoted 8 lines · David Hildenbrand (Arm)

Quoted 7 lines · Yeoreum Yun

True. I overlooked guard bit is sticky.

It's enough but alloc_isolated_mem() could be modified to allocate with PROT_NONE first and then change the prot.

Quoted 6 lines

Quoted 4 lines

It seems whether make a helper or testcase should write the code properly in case of unwanted VMA merge.

IMHO, instead of testcase write them all

So far I am aware of exactly one test case, which others do absolutely need this?

True. I'll respin with your suggestion.

Quoted 12 lines · Yeoreum Yun

Quoted 11 lines · David Hildenbrand (Arm)

Quoted 10 lines · Yeoreum Yun

True. I overlooked guard bit is sticky.

It's enough but alloc_isolated_mem() could be modified to allocate with PROT_NONE first and then change the prot.

It seems whether make a helper or testcase should write the code properly in case of unwanted VMA merge.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

IMHO, instead of testcase write them all

So far I am aware of exactly one test case, which others do absolutely need this?

True. I'll respin with your suggestion.

Don't get me wrong, if we'll need this for other tests we can add helpers. But for a single user adding a helper is not really worth it.

split_huge_page_test can fail for the following reasons:

1. During the test, khugepaged may collapse previously split pages again, causing intermittent failures.

2. Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on AArch64”), glibc may call madvise(MADV_HUGEPAGE) for sufficiently large allocations made by memalign(). The underlying VMA may start at a different address from the aligned address returned by memalign(). Moreover, a subsequent madvise(MADV_HUGEPAGE) call does not split the VMA because it already has the same advice.

This causes the test to fail because the check_huge_xxx() helpers incorrectly require the address returned by memalign() to match the VMA start address reported in /proc/self/smaps.

Address these issues by applying MADV_NOHUGEPAGE after faulting in the huge page, preventing khugepaged from collapsing it again, and instead of relying on /proc/self/smaps, use /proc/self/pagemap and /proc/kpageflags to detect huge-page mappings and large folios:

1. If hpage_size == pmd_pagesize, check PAGE_IS_HUGE instead of using check_large_folios(), since only the mapping type matters. This identifies PMD-mapped huge pages.
2. Otherwise, use check_large_folios() to detect large folios. This covers mTHP cases.
3. Check the folio flags according to the type of huge page.

Also, current usage of memalign() would result memory area may unexpectedly merge with an adjacent VMA, causing tests that inspect it through /proc/self/smaps to fail.

Quoted 28 lines

split_huge_page_test can fail for the following reasons:

1. During the test, khugepaged may collapse previously split pages again, causing intermittent failures.

2. Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on AArch64”), glibc may call madvise(MADV_HUGEPAGE) for sufficiently large allocations made by memalign(). The underlying VMA may start at a different address from the aligned address returned by memalign(). Moreover, a subsequent madvise(MADV_HUGEPAGE) call does not split the VMA because it already has the same advice.

This causes the test to fail because the check_huge_xxx() helpers incorrectly require the address returned by memalign() to match the VMA start address reported in /proc/self/smaps.

Address these issues by applying MADV_NOHUGEPAGE after faulting in the huge page, preventing khugepaged from collapsing it again, and instead of relying on /proc/self/smaps, use /proc/self/pagemap and /proc/kpageflags to detect huge-page mappings and large folios:

1. If hpage_size == pmd_pagesize, check PAGE_IS_HUGE instead of using check_large_folios(), since only the mapping type matters. This identifies PMD-mapped huge pages.
2. Otherwise, use check_large_folios() to detect large folios. This covers mTHP cases.
3. Check the folio flags according to the type of huge page.

Quoted 3 lines

Also, current usage of memalign() would result memory area may unexpectedly merge with an adjacent VMA, causing tests that inspect it through /proc/self/smaps to fail.

I'm not particularly happy about this.

Relying on VMA merging details rather hints that we shouldn't be using smaps to query some stats/properties.

Which exact things are test querying through /proc/self/smaps? Could we convert the code to just query that stuff through different interfaces?

Quoted 37 lines · Yeoreum Yun

Quoted 28 lines

split_huge_page_test can fail for the following reasons:

1. During the test, khugepaged may collapse previously split pages again, causing intermittent failures.

2. Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on AArch64”), glibc may call madvise(MADV_HUGEPAGE) for sufficiently large allocations made by memalign(). The underlying VMA may start at a different address from the aligned address returned by memalign(). Moreover, a subsequent madvise(MADV_HUGEPAGE) call does not split the VMA because it already has the same advice.

This causes the test to fail because the check_huge_xxx() helpers incorrectly require the address returned by memalign() to match the VMA start address reported in /proc/self/smaps.

Address these issues by applying MADV_NOHUGEPAGE after faulting in the huge page, preventing khugepaged from collapsing it again, and instead of relying on /proc/self/smaps, use /proc/self/pagemap and /proc/kpageflags to detect huge-page mappings and large folios:

1. If hpage_size == pmd_pagesize, check PAGE_IS_HUGE instead of using check_large_folios(), since only the mapping type matters. This identifies PMD-mapped huge pages.
2. Otherwise, use check_large_folios() to detect large folios. This covers mTHP cases.
3. Check the folio flags according to the type of huge page.

Quoted 3 lines

Also, current usage of memalign() would result memory area may unexpectedly merge with an adjacent VMA, causing tests that inspect it through /proc/self/smaps to fail.

I'm not particularly happy about this.

Relying on VMA merging details rather hints that we shouldn't be using smaps to query some stats/properties.

Quoted 2 lines

Which exact things are test querying through /proc/self/smaps? Could we convert the code to just query that stuff through different interfaces?

Well, users currently for using /proc/self/smaps are for check vm-flags:
- guard-regions where using check_vmflags_guard()
- pfnmap test where uses check_vmflag_pfnmap()

Quoted 37 lines · Yeoreum Yun

Quoted 37 lines · Yeoreum Yun

Quoted 28 lines

split_huge_page_test can fail for the following reasons:

1. During the test, khugepaged may collapse previously split pages again, causing intermittent failures.

2. Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on AArch64”), glibc may call madvise(MADV_HUGEPAGE) for sufficiently large allocations made by memalign(). The underlying VMA may start at a different address from the aligned address returned by memalign(). Moreover, a subsequent madvise(MADV_HUGEPAGE) call does not split the VMA because it already has the same advice.

This causes the test to fail because the check_huge_xxx() helpers incorrectly require the address returned by memalign() to match the VMA start address reported in /proc/self/smaps.

Address these issues by applying MADV_NOHUGEPAGE after faulting in the huge page, preventing khugepaged from collapsing it again, and instead of relying on /proc/self/smaps, use /proc/self/pagemap and /proc/kpageflags to detect huge-page mappings and large folios:

1. If hpage_size == pmd_pagesize, check PAGE_IS_HUGE instead of using check_large_folios(), since only the mapping type matters. This identifies PMD-mapped huge pages.
2. Otherwise, use check_large_folios() to detect large folios. This covers mTHP cases.
3. Check the folio flags according to the type of huge page.

Quoted 3 lines

Also, current usage of memalign() would result memory area may unexpectedly merge with an adjacent VMA, causing tests that inspect it through /proc/self/smaps to fail.

I'm not particularly happy about this.

Relying on VMA merging details rather hints that we shouldn't be using smaps to query some stats/properties.

Quoted 6 lines

Quoted 2 lines

Which exact things are test querying through /proc/self/smaps? Could we convert the code to just query that stuff through different interfaces?

Well, users currently for using /proc/self/smaps are for check vm-flags:
- guard-regions where using check_vmflags_guard()
- pfnmap test where uses check_vmflag_pfnmap()

Most vm-flags should not be an issue when it comes to merging. The only exception are vmflags that do not prevent VMA merging.

So it's VM_SOFTDIRTY and VM_MAYBE_GUARD. And I agree that for guard-regions.c we likely have to care such that we don't merge by accident with other VMAs (guard regions).

But that's independent of memalign.

ptr = mmap_(self, variant, NULL, 10 * page_size, PROT_READ | PROT_WRITE, 0, 0); ASSERT_FALSE(check_vmflag_guard(ptr));

could be problematic on its own (unlikely but possible).

For other flags, you really only have to find the smaps area that covers the given address and look at the vm-flags.

Or am I missing something important?

(merging vnas with VM_PFNMAP is impossible right now IIRC)

Quoted 15 lines · David Hildenbrand (Arm)

Quoted 4 lines · Yeoreum Yun

Well, users currently for using /proc/self/smaps are for check vm-flags:
- guard-regions where using check_vmflags_guard()
- pfnmap test where uses check_vmflag_pfnmap()

Most vm-flags should not be an issue when it comes to merging. The only exception are vmflags that do not prevent VMA merging.

So it's VM_SOFTDIRTY and VM_MAYBE_GUARD. And I agree that for guard-regions.c we likely have to care such that we don't merge by accident with other VMAs (guard regions).

But that's independent of memalign.

Quoted 4 lines

ptr = mmap_(self, variant, NULL, 10 * page_size, PROT_READ | PROT_WRITE, 0, 0); ASSERT_FALSE(check_vmflag_guard(ptr));

could be problematic on its own (unlikely but possible).

Yes. That's why I'm think it would be good to use alloc_isolated_mem() in case of ANON mapping for this case.

Quoted 8 lines

For other flags, you really only have to find the smaps area that covers the given address and look at the vm-flags.

Or am I missing something important?

(merging vnas with VM_PFNMAP is impossible right now IIRC)

No. what I want to say including the patch #3 is for the above case where you point out -- ASSERT_FALSE(check_vmflag_guard(ptr)).

Since we don't have any interface to check vm_flags execpt smap and for memory mmaped with anon would have a chance to merge, We need something to replace memalign() with preventing unexpected VMA merge.

Quoted 16 lines · Yeoreum Yun

Quoted 15 lines · David Hildenbrand (Arm)

Quoted 4 lines · Yeoreum Yun

Well, users currently for using /proc/self/smaps are for check vm-flags:
- guard-regions where using check_vmflags_guard()
- pfnmap test where uses check_vmflag_pfnmap()

Most vm-flags should not be an issue when it comes to merging. The only exception are vmflags that do not prevent VMA merging.

So it's VM_SOFTDIRTY and VM_MAYBE_GUARD. And I agree that for guard-regions.c we likely have to care such that we don't merge by accident with other VMAs (guard regions).

But that's independent of memalign.

Quoted 7 lines

Quoted 4 lines

ptr = mmap_(self, variant, NULL, 10 * page_size, PROT_READ | PROT_WRITE, 0, 0); ASSERT_FALSE(check_vmflag_guard(ptr));

could be problematic on its own (unlikely but possible).

Yes. That's why I'm think it would be good to use alloc_isolated_mem() in case of ANON mapping for this case.

It's really only guest-region code that needs this.

Quoted 12 lines

Quoted 8 lines

For other flags, you really only have to find the smaps area that covers the given address and look at the vm-flags.

Or am I missing something important?

(merging vnas with VM_PFNMAP is impossible right now IIRC)

No. what I want to say including the patch #3 is for the above case where you point out -- ASSERT_FALSE(check_vmflag_guard(ptr)).

Quoted 4 lines

Since we don't have any interface to check vm_flags execpt smap and for memory mmaped with anon would have a chance to merge, We need something to replace memalign() with preventing unexpected VMA merge.

Only for the cases that actually really needs this, which is in my understanding guard-regions.

And I repeat, this is not a memalign() problem.