public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Tarun Sahu <tsahu@linux.ibm.com>
To: ltp@lists.linux.it
Cc: geetika@linux.ibm.com, sbhat@linux.ibm.com,
	aneesh.kumar@linux.ibm.com, vaibhav@linux.ibm.com,
	rpalethorpe@suse.com
Subject: [LTP] [PATCH v2 3/8] Hugetlb: Migrating libhugetlbfs huge_below_4GB_normal_above
Date: Tue, 20 Dec 2022 12:01:04 +0530	[thread overview]
Message-ID: <20221220063109.279007-4-tsahu@linux.ibm.com> (raw)
In-Reply-To: <20221220063109.279007-1-tsahu@linux.ibm.com>

Migrating the libhugetlbfs/testcases/huge_below_4GB_normal_above.c test

Test Description: On some old ppc64 kernel, when huge page is mapped at
below touching 32 bit boundary (4GB - hpage_size), and normal page is
mmaped at just above it, it triggers a bug caused by off-by-one error.

Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
---
 runtest/hugetlb                               |   1 +
 testcases/kernel/mem/.gitignore               |   1 +
 .../kernel/mem/hugetlb/hugemmap/hugemmap14.c  | 159 ++++++++++++++++++
 3 files changed, 161 insertions(+)
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap14.c

diff --git a/runtest/hugetlb b/runtest/hugetlb
index 2029ee4b3..796ebe7fa 100644
--- a/runtest/hugetlb
+++ b/runtest/hugetlb
@@ -15,6 +15,7 @@ hugemmap10 hugemmap10
 hugemmap11 hugemmap11
 hugemmap12 hugemmap12
 hugemmap13 hugemmap13
+hugemmap14 hugemmap14
 hugemmap05_1 hugemmap05 -m
 hugemmap05_2 hugemmap05 -s
 hugemmap05_3 hugemmap05 -s -m
diff --git a/testcases/kernel/mem/.gitignore b/testcases/kernel/mem/.gitignore
index 5955ed613..3106579ce 100644
--- a/testcases/kernel/mem/.gitignore
+++ b/testcases/kernel/mem/.gitignore
@@ -14,6 +14,7 @@
 /hugetlb/hugemmap/hugemmap11
 /hugetlb/hugemmap/hugemmap12
 /hugetlb/hugemmap/hugemmap13
+/hugetlb/hugemmap/hugemmap14
 /hugetlb/hugeshmat/hugeshmat01
 /hugetlb/hugeshmat/hugeshmat02
 /hugetlb/hugeshmat/hugeshmat03
diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap14.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap14.c
new file mode 100644
index 000000000..13068e5b6
--- /dev/null
+++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap14.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: LGPL-2.1-or-later
+/*
+ * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
+ * Author: David Gibson & Adam Litke
+ */
+
+/*\
+ * [Description]
+ * On some old ppc64 kernel, when huge page is mapped at below touching
+ * 32 bit boundary (4GB - hpage_size), and normal page is mmaped
+ * at just above it, it triggers a bug caused by off-by-one error.
+ *
+ * WARNING: The offsets and addresses used within are specifically
+ * calculated to trigger the bug as it existed.  Don't mess with them
+ * unless you *really* know what you're doing.
+ */
+
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <sys/mount.h>
+#include <limits.h>
+#include <sys/param.h>
+#include <sys/types.h>
+
+#include "hugetlb.h"
+
+#define FOURGB (1UL << 32)
+#define MNTPOINT "hugetlbfs/"
+static int  fd = -1;
+static unsigned long hpage_size;
+static int page_size;
+
+static void run_test(void)
+{
+	void *p, *q = NULL, *r = NULL;
+	unsigned long lowaddr, highaddr;
+	unsigned long below_start;
+	unsigned long above_end;
+
+	/*
+	 * We use a low address right below 4GB so we can test for
+	 * off-by-one errors
+	 */
+	lowaddr = FOURGB - hpage_size;
+	tst_res(TINFO, "Mapping hugepage at %lx...", lowaddr);
+	p = mmap((void *)lowaddr, hpage_size, PROT_READ|PROT_WRITE,
+		 MAP_SHARED|MAP_FIXED, fd, 0);
+	if (p == MAP_FAILED) {
+		/* This is last low slice - 256M just before 4G */
+		below_start = FOURGB - 256L*1024*1024;
+		above_end = FOURGB;
+
+		if (range_is_mapped(below_start, above_end) == 1) {
+			tst_res(TINFO|TERRNO, "region (4G-256M)-4G is not free & "
+					"mmap() failed expected");
+			tst_res(TPASS, "Successful but inconclusive");
+		} else
+			tst_res(TFAIL|TERRNO, "mmap() huge failed unexpected");
+		goto cleanup;
+	}
+	if (p != (void *)lowaddr) {
+		tst_res(TFAIL, "Wrong address with MAP_FIXED huge");
+		goto cleanup;
+	}
+	memset(p, 0, hpage_size);
+
+	/* Test for off by one errors */
+	highaddr = FOURGB;
+	tst_res(TINFO, "Mapping normal page at %lx...", highaddr);
+	q = mmap((void *)highaddr, page_size, PROT_READ|PROT_WRITE,
+		 MAP_SHARED|MAP_FIXED|MAP_ANONYMOUS, 0, 0);
+	if (q == MAP_FAILED) {
+		below_start = FOURGB;
+		above_end = FOURGB + page_size;
+
+		if (range_is_mapped(below_start, above_end) == 1) {
+			tst_res(TINFO|TERRNO, "region 4G-(4G+page) is not free & "
+					"mmap() failed expected");
+			tst_res(TPASS, "Successful but inconclusive");
+		} else
+			tst_res(TFAIL|TERRNO, "mmap() normal 1 failed unexpected");
+		goto cleanup;
+	}
+	if (q != (void *)highaddr) {
+		tst_res(TFAIL, "Wrong address with MAP_FIXED normal 1");
+		goto cleanup;
+	}
+	memset(q, 0, page_size);
+
+	/*
+	 * Why this address?  Well on ppc64, we're working with 256MB
+	 * segment numbers, hence >>28.  In practice the shift
+	 * instructions only start wrapping around with shifts 128 or
+	 * greater.
+	 */
+	highaddr = ((lowaddr >> 28) + 128) << 28;
+	tst_res(TINFO, "Mapping normal page at %lx...", highaddr);
+	r = mmap((void *)highaddr, page_size, PROT_READ|PROT_WRITE,
+		 MAP_SHARED|MAP_FIXED|MAP_ANONYMOUS, 0, 0);
+	if (r == MAP_FAILED) {
+		below_start = highaddr;
+		above_end = highaddr + page_size;
+
+		if (range_is_mapped(below_start, above_end) == 1) {
+			tst_res(TINFO|TERRNO, "region haddr-(haddr+page) not free & "
+					"mmap() failed unexpected");
+			tst_res(TPASS, "Successful but inconclusive");
+		}
+		tst_res(TFAIL|TERRNO, "mmap() normal 2 failed unexpected");
+		goto cleanup;
+	}
+	if (r != (void *)highaddr) {
+		tst_res(TFAIL, "Wrong address with MAP_FIXED normal 2");
+		goto cleanup;
+	}
+	memset(r, 0, page_size);
+	tst_res(TPASS, "Successful");
+
+cleanup:
+	if (p && p != MAP_FAILED)
+		SAFE_MUNMAP(p, hpage_size);
+	if (q && q != MAP_FAILED)
+		SAFE_MUNMAP(q, page_size);
+	if (r && r != MAP_FAILED)
+		SAFE_MUNMAP(r, page_size);
+}
+
+static void setup(void)
+{
+	page_size = getpagesize();
+	hpage_size = SAFE_READ_MEMINFO("Hugepagesize:")*1024;
+
+	if (sizeof(void *) <= 4)
+		tst_brk(TCONF, "Machine must be >32 bit");
+	if (hpage_size > FOURGB)
+		tst_brk(TCONF, "Huge page size is too large");
+	fd = tst_creat_unlinked(MNTPOINT, 0);
+}
+
+static void cleanup(void)
+{
+	if (fd > 0)
+		SAFE_CLOSE(fd);
+}
+
+static struct tst_test test = {
+	.tags = (struct tst_tag[]) {
+		{"linux-git", "9a94c5793a7b"},
+		{}
+	},
+	.needs_root = 1,
+	.mntpoint = MNTPOINT,
+	.needs_hugetlbfs = 1,
+	.needs_tmpdir = 1,
+	.setup = setup,
+	.cleanup = cleanup,
+	.test_all = run_test,
+	.hugepages = {2, TST_NEEDS},
+};
-- 
2.31.1


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  parent reply	other threads:[~2022-12-20  6:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-20  6:31 [LTP] [PATCH v2 0/8][PART 3] Hugetlb:Migrating the libhugetlbfs tests Tarun Sahu
2022-12-20  6:31 ` [LTP] [PATCH v2 1/8] Hugetlb: Migrating libhugetlbfs fork-cow Tarun Sahu
2022-12-20  6:31 ` [LTP] [PATCH v2 2/8] Hugetlb: Migrating libhugetlbfs huge_at_4GB_normal_below Tarun Sahu
2022-12-20  6:31 ` Tarun Sahu [this message]
2022-12-20  6:31 ` [LTP] [PATCH v2 4/8] Hugetlb: Migrating libhugetlbfs icache-hygiene Tarun Sahu
2023-01-25  1:11   ` Petr Vorel
2022-12-20  6:31 ` [LTP] [PATCH v2 5/8] Hugetlb: Migrating libhugetlbfs madvise_reserve Tarun Sahu
2022-12-20  6:31 ` [LTP] [PATCH v2 6/8] Hugetlb: Migrating libhugetlbfs map_high_truncate_2 Tarun Sahu
2022-12-20  6:31 ` [LTP] [PATCH v2 7/8] Hugetlb: Migrating libhugetlbfs misalign Tarun Sahu
2022-12-20  6:31 ` [LTP] [PATCH v2 8/8] Hugetlb: Migrating libhugetlbfs misaligned_offset Tarun Sahu
2022-12-20 12:48 ` [LTP] [PATCH v2 0/8][PART 3] Hugetlb:Migrating the libhugetlbfs tests Richard Palethorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221220063109.279007-4-tsahu@linux.ibm.com \
    --to=tsahu@linux.ibm.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=geetika@linux.ibm.com \
    --cc=ltp@lists.linux.it \
    --cc=rpalethorpe@suse.com \
    --cc=sbhat@linux.ibm.com \
    --cc=vaibhav@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox