[LTP] [PATCH 0/8][PART 3] Hugetlb:Migrating the libhugetlbfs tests

[LTP] [PATCH 0/8][PART 3] Hugetlb:Migrating the libhugetlbfs tests

[Tarun Sahu]

-- resending as a fresh series, [3] was sent mistakenly in reply to [2].

Hi,
This patch series is in continuation to part [1] and part [2]
This series include 8 more tests taken from libhugetlbfs.

Background:
Libhugetlbfs is not being maintained actively, and some distro is dropping
support for it. There are some tests that are good for testing hugetlb
functionality in kernel. These patches include tests from libhugetlbfs.

ref:
 1. https://lore.kernel.org/all/20221104162511.28658-1-tsahu@linux.ibm.com/
 2. https://lore.kernel.org/all/20221120191533.164848-1-tsahu@linux.ibm.com/
 3. https://lore.kernel.org/all/20221201120248.139396-1-tsahu@linux.ibm.com/
Tarun Sahu (8):
  Hugetlb: Migrating libhugetlbfs fork-cow
  Hugetlb: Migrating libhugetlbfs huge_at_4GB_normal_below
  Hugetlb: Migrating libhugetlbfs huge_below_4GB_normal_above
  Hugetlb: Migrating libhugetlbfs icache-hygiene
  Hugetlb: Migrating libhugetlbfs madvise_reserve
  Hugetlb: Migrating libhugetlbfs map_high_truncate_2
  Hugetlb: Migrating libhugetlbfs misalign
  Hugetlb: Migrating libhugetlbfs misaligned_offset

 runtest/hugetlb                               |   9 +
 testcases/kernel/mem/.gitignore               |   8 +
 .../kernel/mem/hugetlb/hugefork/Makefile      |  10 +
 .../kernel/mem/hugetlb/hugefork/hugefork01.c  | 108 ++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap13.c  | 122 +++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap14.c  | 156 ++++++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap15.c  | 239 ++++++++++++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap16.c  |  83 ++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap17.c  | 103 ++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap18.c  | 153 +++++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap19.c  | 147 +++++++++++
 11 files changed, 1138 insertions(+)
 create mode 100644 testcases/kernel/mem/hugetlb/hugefork/Makefile
 create mode 100644 testcases/kernel/mem/hugetlb/hugefork/hugefork01.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap14.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap15.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap16.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap17.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap18.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap19.c

-- 
2.31.1


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

[LTP] [PATCH 1/8] Hugetlb: Migrating libhugetlbfs fork-cow

[Tarun Sahu]

Migrating the libhugetlbfs/testcases/fork-cow.c test

Test Description: This checks copy-on-write semantics, specifically the
semantics of a MAP_PRIVATE mapping across a fork().  Some versions of the
powerpc kernel had a bug in huge_ptep_set_wrprotect() which would fail to
flush the hash table after setting the write protect bit in the parent's
page tables, thus allowing the parent to pollute the child's mapping.

Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
---
 runtest/hugetlb                               |   2 +
 testcases/kernel/mem/.gitignore               |   1 +
 .../kernel/mem/hugetlb/hugefork/Makefile      |  10 ++
 .../kernel/mem/hugetlb/hugefork/hugefork01.c  | 108 ++++++++++++++++++
 4 files changed, 121 insertions(+)
 create mode 100644 testcases/kernel/mem/hugetlb/hugefork/Makefile
 create mode 100644 testcases/kernel/mem/hugetlb/hugefork/hugefork01.c

diff --git a/runtest/hugetlb b/runtest/hugetlb
index ec1fc2515..4c16e1e7c 100644
--- a/runtest/hugetlb
+++ b/runtest/hugetlb
@@ -1,6 +1,8 @@
 hugefallocate01 hugefallocate01
 hugefallocate02 hugefallocate02
 
+hugefork01 hugefork01
+
 hugemmap01 hugemmap01
 hugemmap02 hugemmap02
 hugemmap04 hugemmap04
diff --git a/testcases/kernel/mem/.gitignore b/testcases/kernel/mem/.gitignore
index c0906f3d3..adea760c7 100644
--- a/testcases/kernel/mem/.gitignore
+++ b/testcases/kernel/mem/.gitignore
@@ -1,6 +1,7 @@
 /cpuset/cpuset01
 /hugetlb/hugefallocate/hugefallocate01
 /hugetlb/hugefallocate/hugefallocate02
+/hugetlb/hugefork/hugefork01
 /hugetlb/hugemmap/hugemmap01
 /hugetlb/hugemmap/hugemmap02
 /hugetlb/hugemmap/hugemmap04
diff --git a/testcases/kernel/mem/hugetlb/hugefork/Makefile b/testcases/kernel/mem/hugetlb/hugefork/Makefile
new file mode 100644
index 000000000..77ebb0aef
--- /dev/null
+++ b/testcases/kernel/mem/hugetlb/hugefork/Makefile
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+# Copyright (C) 2009, Cisco Systems Inc.
+# Ngie Cooper, July 2009
+
+top_srcdir		?= ../../../../..
+
+include $(top_srcdir)/include/mk/testcases.mk
+include $(abs_srcdir)/../Makefile.inc
+include $(top_srcdir)/include/mk/generic_leaf_target.mk
+
diff --git a/testcases/kernel/mem/hugetlb/hugefork/hugefork01.c b/testcases/kernel/mem/hugetlb/hugefork/hugefork01.c
new file mode 100644
index 000000000..b59c461e3
--- /dev/null
+++ b/testcases/kernel/mem/hugetlb/hugefork/hugefork01.c
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: LGPL-2.1-or-later
+/*
+ * Copyright (C) 2008 David Gibson, IBM Corporation.
+ * Author: David Gibson
+ */
+
+/*\
+ * [Description]
+ *
+ * This checks copy-on-write semantics, specifically the semantics of a
+ * MAP_PRIVATE mapping across a fork().  Some versions of the powerpc
+ * kernel had a bug in huge_ptep_set_wrprotect() which would fail to
+ * flush the hash table after setting the write protect bit in the parent's
+ * page tables, thus allowing the parent to pollute the child's mapping.
+ *
+ */
+
+#include <sys/wait.h>
+#include <sys/mman.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <sys/types.h>
+
+#include "hugetlb.h"
+
+#define RANDOM_CONSTANT		0x1234ABCD
+#define OTHER_CONSTANT		0xfeef5678
+#define MNTPOINT "hugetlbfs/"
+static int  fd = -1;
+static long hpage_size;
+
+static void run_test(void)
+{
+	int status;
+	volatile unsigned int *p;
+	volatile unsigned int *child_readback;
+	int parent_readback;
+	pid_t pid;
+
+	child_readback = SAFE_MMAP(NULL, getpagesize(), PROT_READ|PROT_WRITE,
+			MAP_SHARED|MAP_ANONYMOUS, -1, 0);
+	*child_readback = 0;
+
+	p = SAFE_MMAP(NULL, hpage_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
+	*p = RANDOM_CONSTANT;
+
+	pid = SAFE_FORK();
+	if (pid != 0) {
+		*p = ~RANDOM_CONSTANT;
+		TST_CHECKPOINT_WAKE_AND_WAIT(0);
+		parent_readback = *p;
+		TST_CHECKPOINT_WAKE(0);
+	} else {
+		TST_CHECKPOINT_WAIT(0);
+		*child_readback = *p;
+		*p = OTHER_CONSTANT;
+		TST_CHECKPOINT_WAKE_AND_WAIT(0);
+		exit(0);
+	}
+
+	SAFE_WAITPID(pid, &status, 0);
+	if (WEXITSTATUS(status) != 0) {
+		tst_res(TFAIL, "Child failed: %d", WEXITSTATUS(status));
+		goto cleanup;
+	}
+
+	tst_res(TINFO, "child_readback = 0x%x, parent_readback = 0x%x",
+			*child_readback, parent_readback);
+
+	if (*child_readback != RANDOM_CONSTANT) {
+		tst_res(TFAIL, "Child read back 0x%x instead of 0x%x",
+		     *child_readback, RANDOM_CONSTANT);
+		goto cleanup;
+	}
+	if (parent_readback != ~RANDOM_CONSTANT) {
+		tst_res(TFAIL, "Parent read back 0x%x instead of 0x%x",
+		     parent_readback, RANDOM_CONSTANT);
+	} else
+		tst_res(TPASS, "Parent and child both read the expected values.");
+
+cleanup:
+	SAFE_MUNMAP((void *)p, hpage_size);
+	SAFE_MUNMAP((void *)child_readback, getpagesize());
+}
+
+static void setup(void)
+{
+	hpage_size = SAFE_READ_MEMINFO("Hugepagesize:")*1024;
+	fd = tst_creat_unlinked(MNTPOINT, 0);
+}
+
+static void cleanup(void)
+{
+	if (fd > 0)
+		SAFE_CLOSE(fd);
+}
+
+static struct tst_test test = {
+	.needs_root = 1,
+	.needs_checkpoints = 1,
+	.mntpoint = MNTPOINT,
+	.needs_hugetlbfs = 1,
+	.forks_child = 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

Re: [LTP] [PATCH 1/8] Hugetlb: Migrating libhugetlbfs fork-cow

[Richard Palethorpe]

Hello,

Tarun Sahu <tsahu@linux.ibm.com> writes:

> Migrating the libhugetlbfs/testcases/fork-cow.c test
>
> Test Description: This checks copy-on-write semantics, specifically the
> semantics of a MAP_PRIVATE mapping across a fork().  Some versions of the
> powerpc kernel had a bug in huge_ptep_set_wrprotect() which would fail to
> flush the hash table after setting the write protect bit in the parent's
> page tables, thus allowing the parent to pollute the child's mapping.
>
> Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
> ---
>  runtest/hugetlb                               |   2 +
>  testcases/kernel/mem/.gitignore               |   1 +
>  .../kernel/mem/hugetlb/hugefork/Makefile      |  10 ++
>  .../kernel/mem/hugetlb/hugefork/hugefork01.c  | 108 ++++++++++++++++++
>  4 files changed, 121 insertions(+)
>  create mode 100644 testcases/kernel/mem/hugetlb/hugefork/Makefile
>  create mode 100644 testcases/kernel/mem/hugetlb/hugefork/hugefork01.c
>
> diff --git a/runtest/hugetlb b/runtest/hugetlb
n> index ec1fc2515..4c16e1e7c 100644
> --- a/runtest/hugetlb
> +++ b/runtest/hugetlb
> @@ -1,6 +1,8 @@
>  hugefallocate01 hugefallocate01
>  hugefallocate02 hugefallocate02
>  
> +hugefork01 hugefork01
> +
>  hugemmap01 hugemmap01
>  hugemmap02 hugemmap02
>  hugemmap04 hugemmap04
> diff --git a/testcases/kernel/mem/.gitignore b/testcases/kernel/mem/.gitignore
> index c0906f3d3..adea760c7 100644
> --- a/testcases/kernel/mem/.gitignore
> +++ b/testcases/kernel/mem/.gitignore
> @@ -1,6 +1,7 @@
>  /cpuset/cpuset01
>  /hugetlb/hugefallocate/hugefallocate01
>  /hugetlb/hugefallocate/hugefallocate02
> +/hugetlb/hugefork/hugefork01
>  /hugetlb/hugemmap/hugemmap01
>  /hugetlb/hugemmap/hugemmap02
>  /hugetlb/hugemmap/hugemmap04
> diff --git a/testcases/kernel/mem/hugetlb/hugefork/Makefile b/testcases/kernel/mem/hugetlb/hugefork/Makefile
> new file mode 100644
> index 000000000..77ebb0aef
> --- /dev/null
> +++ b/testcases/kernel/mem/hugetlb/hugefork/Makefile
> @@ -0,0 +1,10 @@
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +# Copyright (C) 2009, Cisco Systems Inc.
> +# Ngie Cooper, July 2009
> +
> +top_srcdir		?= ../../../../..
> +
> +include $(top_srcdir)/include/mk/testcases.mk
> +include $(abs_srcdir)/../Makefile.inc
> +include $(top_srcdir)/include/mk/generic_leaf_target.mk
> +
> diff --git a/testcases/kernel/mem/hugetlb/hugefork/hugefork01.c b/testcases/kernel/mem/hugetlb/hugefork/hugefork01.c
> new file mode 100644
> index 000000000..b59c461e3
> --- /dev/null
> +++ b/testcases/kernel/mem/hugetlb/hugefork/hugefork01.c
> @@ -0,0 +1,108 @@
> +// SPDX-License-Identifier: LGPL-2.1-or-later
> +/*
> + * Copyright (C) 2008 David Gibson, IBM Corporation.
> + * Author: David Gibson
> + */
> +
> +/*\
> + * [Description]
> + *
> + * This checks copy-on-write semantics, specifically the semantics of a
> + * MAP_PRIVATE mapping across a fork().  Some versions of the powerpc
> + * kernel had a bug in huge_ptep_set_wrprotect() which would fail to
> + * flush the hash table after setting the write protect bit in the parent's
> + * page tables, thus allowing the parent to pollute the child's mapping.
> + *
> + */
> +
> +#include <sys/wait.h>
> +#include <sys/mman.h>
> +#include <stdlib.h>
> +#include <unistd.h>
> +#include <sys/types.h>
> +
> +#include "hugetlb.h"
> +
> +#define RANDOM_CONSTANT		0x1234ABCD
> +#define OTHER_CONSTANT		0xfeef5678

It seems their are actually 3 constants as "random" is inverted. I'd
prefer it if they had names like C1, C2, C3 with no connotations.

> +#define MNTPOINT "hugetlbfs/"
> +static int  fd = -1;
> +static long hpage_size;
> +
> +static void run_test(void)
> +{
> +	int status;
> +	volatile unsigned int *p;
> +	volatile unsigned int *child_readback;
> +	int parent_readback;
> +	pid_t pid;
> +
> +	child_readback = SAFE_MMAP(NULL, getpagesize(), PROT_READ|PROT_WRITE,
> +			MAP_SHARED|MAP_ANONYMOUS, -1, 0);
> +	*child_readback = 0;
> +
> +	p = SAFE_MMAP(NULL, hpage_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
> +	*p = RANDOM_CONSTANT;
> +
> +	pid = SAFE_FORK();
> +	if (pid != 0) {
> +		*p = ~RANDOM_CONSTANT;
> +		TST_CHECKPOINT_WAKE_AND_WAIT(0);
> +		parent_readback = *p;
> +		TST_CHECKPOINT_WAKE(0);
> +	} else {
> +		TST_CHECKPOINT_WAIT(0);
> +		*child_readback = *p;
> +		*p = OTHER_CONSTANT;
> +		TST_CHECKPOINT_WAKE_AND_WAIT(0);
> +		exit(0);
> +	}
> +
> +	SAFE_WAITPID(pid, &status, 0);
> +	if (WEXITSTATUS(status) != 0) {
> +		tst_res(TFAIL, "Child failed: %d", WEXITSTATUS(status));
> +		goto cleanup;
> +	}

This can be replaced with tst_reap_children();

> +
> +	tst_res(TINFO, "child_readback = 0x%x, parent_readback = 0x%x",
> +			*child_readback, parent_readback);
> +
> +	if (*child_readback != RANDOM_CONSTANT) {
> +		tst_res(TFAIL, "Child read back 0x%x instead of 0x%x",
> +		     *child_readback, RANDOM_CONSTANT);

I think this could be checked at the end of the child and the extra mmap
for child_readback removed. The LTP lib already creats some shared
memory with children to propagate results.

Assuming that mmap is not needed for the original bug reproducer.

> +		goto cleanup;

I don't think this is necessary.

> +	}
> +	if (parent_readback != ~RANDOM_CONSTANT) {

These comparisons could be replaced with TST_EXP_EQ_LU or TST_EXP_EXPR.

-- 
Thank you,
Richard.

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

Re: [LTP] [PATCH 1/8] Hugetlb: Migrating libhugetlbfs fork-cow

[Tarun Sahu]

Hi,
Thanks for reviewing it.
On Dec 05 2022, Richard Palethorpe wrote:
> Hello,
> 
> Tarun Sahu <tsahu@linux.ibm.com> writes:
> 
> > +
> > +#include <sys/wait.h>
> > +#include <sys/mman.h>
> > +#include <stdlib.h>
> > +#include <unistd.h>
> > +#include <sys/types.h>
> > +
> > +#include "hugetlb.h"
> > +
> > +#define RANDOM_CONSTANT		0x1234ABCD
> > +#define OTHER_CONSTANT		0xfeef5678
> 
> It seems their are actually 3 constants as "random" is inverted. I'd
> prefer it if they had names like C1, C2, C3 with no connotations.
> 
Yeah, Will be more cleaner, Will update it.

--skip
> > +
> > +	SAFE_WAITPID(pid, &status, 0);
> > +	if (WEXITSTATUS(status) != 0) {
> > +		tst_res(TFAIL, "Child failed: %d", WEXITSTATUS(status));
> > +		goto cleanup;
> > +	}
> 
> This can be replaced with tst_reap_children();
Ok. I will update it in v2.
> 
> > +
> > +	tst_res(TINFO, "child_readback = 0x%x, parent_readback = 0x%x",
> > +			*child_readback, parent_readback);
> > +
> > +	if (*child_readback != RANDOM_CONSTANT) {
> > +		tst_res(TFAIL, "Child read back 0x%x instead of 0x%x",
> > +		     *child_readback, RANDOM_CONSTANT);
> 
> I think this could be checked at the end of the child and the extra mmap
> for child_readback removed. The LTP lib already creats some shared
> memory with children to propagate results.
> 
> Assuming that mmap is not needed for the original bug reproducer.
>
Looking at the fix: 86df86424939d316 ("Correct hash flushing from huge_ptep_set_wrprotect()")
seems it can be done. I will look at it and will update it in v2.
> > +		goto cleanup;
> 
> I don't think this is necessary.
> 
> > +	}
> > +	if (parent_readback != ~RANDOM_CONSTANT) {
> 
> These comparisons could be replaced with TST_EXP_EQ_LU or TST_EXP_EXPR.
> 
Ok. Will update it.
> -- 
> Thank you,
> Richard.
> 
> -- 
> Mailing list info: https://lists.linux.it/listinfo/ltp

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

Re: [LTP] [PATCH 1/8] Hugetlb: Migrating libhugetlbfs fork-cow

[Richard Palethorpe]

Hello,

Tarun Sahu <tsahu@linux.ibm.com> writes:

> Hi,
> Thanks for reviewing it.
> On Dec 05 2022, Richard Palethorpe wrote:
>> Hello,
>> 
>> Tarun Sahu <tsahu@linux.ibm.com> writes:
>> 
>> > +
>> > +#include <sys/wait.h>
>> > +#include <sys/mman.h>
>> > +#include <stdlib.h>
>> > +#include <unistd.h>
>> > +#include <sys/types.h>
>> > +
>> > +#include "hugetlb.h"
>> > +
>> > +#define RANDOM_CONSTANT		0x1234ABCD
>> > +#define OTHER_CONSTANT		0xfeef5678
>> 
>> It seems their are actually 3 constants as "random" is inverted. I'd
>> prefer it if they had names like C1, C2, C3 with no connotations.
>> 
> Yeah, Will be more cleaner, Will update it.
>
> --skip
>> > +
>> > +	SAFE_WAITPID(pid, &status, 0);
>> > +	if (WEXITSTATUS(status) != 0) {
>> > +		tst_res(TFAIL, "Child failed: %d", WEXITSTATUS(status));
>> > +		goto cleanup;
>> > +	}
>> 
>> This can be replaced with tst_reap_children();
> Ok. I will update it in v2.
>> 
>> > +
>> > +	tst_res(TINFO, "child_readback = 0x%x, parent_readback = 0x%x",
>> > +			*child_readback, parent_readback);
>> > +
>> > +	if (*child_readback != RANDOM_CONSTANT) {
>> > +		tst_res(TFAIL, "Child read back 0x%x instead of 0x%x",
>> > +		     *child_readback, RANDOM_CONSTANT);
>> 
>> I think this could be checked at the end of the child and the extra mmap
>> for child_readback removed. The LTP lib already creats some shared
>> memory with children to propagate results.
>> 
>> Assuming that mmap is not needed for the original bug reproducer.
>>
> Looking at the fix: 86df86424939d316 ("Correct hash flushing from huge_ptep_set_wrprotect()")
> seems it can be done. I will look at it and will update it in v2.

Thanks and as you have the git commit hash, please add this to the tst_test.tags.

>> > +		goto cleanup;
>> 
>> I don't think this is necessary.
>> 
>> > +	}
>> > +	if (parent_readback != ~RANDOM_CONSTANT) {
>> 
>> These comparisons could be replaced with TST_EXP_EQ_LU or TST_EXP_EXPR.
>> 
> Ok. Will update it.
>> -- 
>> Thank you,
>> Richard.
>> 
>> -- 
>> Mailing list info: https://lists.linux.it/listinfo/ltp


-- 
Thank you,
Richard.

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

[LTP] [PATCH 2/8] Hugetlb: Migrating libhugetlbfs huge_at_4GB_normal_below

[Tarun Sahu]

Migrating the libhugetlbfs/testcases/huge_at_4GB_normal_below.c test

Test Description: Designed to pick up a bug on ppc64 where
touches_hugepage_high_range() falsely reported true for ranges reaching
below 4GB

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

diff --git a/runtest/hugetlb b/runtest/hugetlb
index 4c16e1e7c..2029ee4b3 100644
--- a/runtest/hugetlb
+++ b/runtest/hugetlb
@@ -14,6 +14,7 @@ hugemmap09 hugemmap09
 hugemmap10 hugemmap10
 hugemmap11 hugemmap11
 hugemmap12 hugemmap12
+hugemmap13 hugemmap13
 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 adea760c7..5955ed613 100644
--- a/testcases/kernel/mem/.gitignore
+++ b/testcases/kernel/mem/.gitignore
@@ -13,6 +13,7 @@
 /hugetlb/hugemmap/hugemmap10
 /hugetlb/hugemmap/hugemmap11
 /hugetlb/hugemmap/hugemmap12
+/hugetlb/hugemmap/hugemmap13
 /hugetlb/hugeshmat/hugeshmat01
 /hugetlb/hugeshmat/hugeshmat02
 /hugetlb/hugeshmat/hugeshmat03
diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c
new file mode 100644
index 000000000..84a84e074
--- /dev/null
+++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: LGPL-2.1-or-later
+/*
+ * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
+ * Author: David Gibson & Adam Litke
+ */
+
+/*\
+ * [Description]
+ *
+ * Designed to pick up a bug on ppc64 where touches_hugepage_high_range()
+ * falsely reported true for ranges reaching below 4GB
+ *
+ * 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;
+	unsigned long lowaddr;
+	unsigned long below_start;
+	unsigned long above_end;
+
+	p = mmap((void *)FOURGB, hpage_size, PROT_READ|PROT_WRITE,
+		 MAP_SHARED | MAP_FIXED, fd, 0);
+	if (p == MAP_FAILED) {
+		/* slice 0 (high) spans from 4G-1T */
+		below_start = FOURGB;
+		above_end = 1024L*1024*1024*1024;
+
+		if (range_is_mapped(below_start, above_end) == 1) {
+			tst_res(TINFO|TERRNO, "region 4G-IT 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 *)FOURGB) {
+		tst_res(TFAIL, "Wrong address with MAP_FIXED huge");
+		goto cleanup;
+	}
+
+	tst_res(TINFO, "Mapped hugetlb at %p", p);
+
+	memset(p, 0, hpage_size);
+
+	/* Test just below 4GB to check for off-by-one errors */
+	lowaddr = FOURGB - page_size;
+	q = mmap((void *)lowaddr, page_size, PROT_READ|PROT_WRITE,
+		 MAP_SHARED|MAP_FIXED|MAP_ANONYMOUS, 0, 0);
+	if (q == MAP_FAILED) {
+		below_start = FOURGB - page_size;
+		above_end = FOURGB;
+
+		if (range_is_mapped(below_start, above_end) == 1) {
+			tst_res(TINFO|TERRNO, "region (4G-page)-4G is not free & "
+					"mmap() failed expected");
+			tst_res(TPASS, "Successful but inconclusive");
+		} else
+			tst_res(TFAIL|TERRNO, "mmap() normal failed unexpected");
+		goto cleanup;
+	}
+	if (q != (void *)lowaddr) {
+		tst_res(TFAIL, "Wrong address with MAP_FIXED normal");
+		goto cleanup;
+	}
+
+	memset(q, 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);
+}
+
+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 = {
+	.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

Re: [LTP] [PATCH 2/8] Hugetlb: Migrating libhugetlbfs huge_at_4GB_normal_below

[Richard Palethorpe]

Hello,

Tarun Sahu <tsahu@linux.ibm.com> writes:

> Migrating the libhugetlbfs/testcases/huge_at_4GB_normal_below.c test
>
> Test Description: Designed to pick up a bug on ppc64 where
> touches_hugepage_high_range() falsely reported true for ranges reaching
> below 4GB
>
> Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
> ---
>  runtest/hugetlb                               |   1 +
>  testcases/kernel/mem/.gitignore               |   1 +
>  .../kernel/mem/hugetlb/hugemmap/hugemmap13.c  | 122 ++++++++++++++++++
>  3 files changed, 124 insertions(+)
>  create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c
>
> diff --git a/runtest/hugetlb b/runtest/hugetlb
> index 4c16e1e7c..2029ee4b3 100644
> --- a/runtest/hugetlb
> +++ b/runtest/hugetlb
> @@ -14,6 +14,7 @@ hugemmap09 hugemmap09
>  hugemmap10 hugemmap10
>  hugemmap11 hugemmap11
>  hugemmap12 hugemmap12
> +hugemmap13 hugemmap13
>  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 adea760c7..5955ed613 100644
> --- a/testcases/kernel/mem/.gitignore
> +++ b/testcases/kernel/mem/.gitignore
> @@ -13,6 +13,7 @@
>  /hugetlb/hugemmap/hugemmap10
>  /hugetlb/hugemmap/hugemmap11
>  /hugetlb/hugemmap/hugemmap12
> +/hugetlb/hugemmap/hugemmap13
>  /hugetlb/hugeshmat/hugeshmat01
>  /hugetlb/hugeshmat/hugeshmat02
>  /hugetlb/hugeshmat/hugeshmat03
> diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c
> new file mode 100644
> index 000000000..84a84e074
> --- /dev/null
> +++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c
> @@ -0,0 +1,122 @@
> +// SPDX-License-Identifier: LGPL-2.1-or-later
> +/*
> + * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
> + * Author: David Gibson & Adam Litke
> + */
> +
> +/*\
> + * [Description]
> + *
> + * Designed to pick up a bug on ppc64 where touches_hugepage_high_range()
> + * falsely reported true for ranges reaching below 4GB

Hhmm seems like the macro no longer exists. This isn't a great test
description.

This appers to be the fix for the bug mentioned:
https://lkml.org/lkml/2005/11/23/540

Maybe we could add to this that the test creates a hugepage just above
the 32bit memory space and a normal page below it. That on old kernels
this would trigger a bug caused by an off-by-one error.

-- 
Thank you,
Richard.

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

Re: [LTP] [PATCH 2/8] Hugetlb: Migrating libhugetlbfs huge_at_4GB_normal_below

[Tarun Sahu]

Hi Richard,
Thanks for reviewing it.
On Dec 05 2022, Richard Palethorpe wrote:
> Hello,
> 
> Tarun Sahu <tsahu@linux.ibm.com> writes:
> 
> > Migrating the libhugetlbfs/testcases/huge_at_4GB_normal_below.c test
> >
> > Test Description: Designed to pick up a bug on ppc64 where
> > touches_hugepage_high_range() falsely reported true for ranges reaching
> > below 4GB
> >
> > Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
> > ---
> >  runtest/hugetlb                               |   1 +
> >  testcases/kernel/mem/.gitignore               |   1 +
> >  .../kernel/mem/hugetlb/hugemmap/hugemmap13.c  | 122 ++++++++++++++++++
> >  3 files changed, 124 insertions(+)
> >  create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c
> >
> > diff --git a/runtest/hugetlb b/runtest/hugetlb
> > index 4c16e1e7c..2029ee4b3 100644
> > --- a/runtest/hugetlb
> > +++ b/runtest/hugetlb
> > @@ -14,6 +14,7 @@ hugemmap09 hugemmap09
> >  hugemmap10 hugemmap10
> >  hugemmap11 hugemmap11
> >  hugemmap12 hugemmap12
> > +hugemmap13 hugemmap13
> >  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 adea760c7..5955ed613 100644
> > --- a/testcases/kernel/mem/.gitignore
> > +++ b/testcases/kernel/mem/.gitignore
> > @@ -13,6 +13,7 @@
> >  /hugetlb/hugemmap/hugemmap10
> >  /hugetlb/hugemmap/hugemmap11
> >  /hugetlb/hugemmap/hugemmap12
> > +/hugetlb/hugemmap/hugemmap13
> >  /hugetlb/hugeshmat/hugeshmat01
> >  /hugetlb/hugeshmat/hugeshmat02
> >  /hugetlb/hugeshmat/hugeshmat03
> > diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c
> > new file mode 100644
> > index 000000000..84a84e074
> > --- /dev/null
> > +++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c
> > @@ -0,0 +1,122 @@
> > +// SPDX-License-Identifier: LGPL-2.1-or-later
> > +/*
> > + * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
> > + * Author: David Gibson & Adam Litke
> > + */
> > +
> > +/*\
> > + * [Description]
> > + *
> > + * Designed to pick up a bug on ppc64 where touches_hugepage_high_range()
> > + * falsely reported true for ranges reaching below 4GB
> 
> Hhmm seems like the macro no longer exists. This isn't a great test
> description.
> 
> This appers to be the fix for the bug mentioned:
> https://lkml.org/lkml/2005/11/23/540
> 
> Maybe we could add to this that the test creates a hugepage just above
> the 32bit memory space and a normal page below it. That on old kernels
> this would trigger a bug caused by an off-by-one error.
> 
Yeah Agree, Will update it in v2.
> -- 
> Thank you,
> Richard.
> 
> -- 
> Mailing list info: https://lists.linux.it/listinfo/ltp

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

[LTP] [PATCH 3/8] Hugetlb: Migrating libhugetlbfs huge_below_4GB_normal_above

[Tarun Sahu]

Migrating the libhugetlbfs/testcases/huge_below_4GB_normal_above.c test

Test Description: Designed to pick up a bug on ppc64 where
touches_hugepage_low_range() could give false positives because of the
peculiar (undefined) behaviour of << for large shifts

Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
---
 runtest/hugetlb                               |   1 +
 testcases/kernel/mem/.gitignore               |   1 +
 .../kernel/mem/hugetlb/hugemmap/hugemmap14.c  | 156 ++++++++++++++++++
 3 files changed, 158 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..8ccd141f8
--- /dev/null
+++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap14.c
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: LGPL-2.1-or-later
+/*
+ * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
+ * Author: David Gibson & Adam Litke
+ */
+
+/*\
+ * [Description]
+ *
+ * Designed to pick up a bug on ppc64 where touches_hugepage_low_range()
+ * could give false positives because of the peculiar (undefined)
+ * behaviour of << for large shifts
+ *
+ * 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 = {
+	.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

Re: [LTP] [PATCH 3/8] Hugetlb: Migrating libhugetlbfs huge_below_4GB_normal_above

[Richard Palethorpe]

Hello,

Tarun Sahu <tsahu@linux.ibm.com> writes:

> Migrating the libhugetlbfs/testcases/huge_below_4GB_normal_above.c test
>
> Test Description: Designed to pick up a bug on ppc64 where
> touches_hugepage_low_range() could give false positives because of the
> peculiar (undefined) behaviour of << for large shifts
>
> Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
> ---
>  runtest/hugetlb                               |   1 +
>  testcases/kernel/mem/.gitignore               |   1 +
>  .../kernel/mem/hugetlb/hugemmap/hugemmap14.c  | 156 ++++++++++++++++++
>  3 files changed, 158 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..8ccd141f8
> --- /dev/null
> +++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap14.c
> @@ -0,0 +1,156 @@
> +// SPDX-License-Identifier: LGPL-2.1-or-later
> +/*
> + * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
> + * Author: David Gibson & Adam Litke
> + */
> +
> +/*\
> + * [Description]
> + *
> + * Designed to pick up a bug on ppc64 where touches_hugepage_low_range()
> + * could give false positives because of the peculiar (undefined)
> + * behaviour of << for large shifts
> + *
> + * 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.

I guess the test is good insofar that I can tell. As with hugemmap13 it
would be nice to have a reference to the bugfix though.

> +
> +static struct tst_test test = {
> +	.needs_root = 1,
> +	.mntpoint = MNTPOINT,
> +	.needs_hugetlbfs = 1,
> +	.needs_tmpdir = 1,
> +	.setup = setup,
> +	.cleanup = cleanup,
> +	.test_all = run_test,
> +	.hugepages = {2, TST_NEEDS},

If we can find the bugfix commit then it can be referenced in the tags
here.

-- 
Thank you,
Richard.

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

Re: [LTP] [PATCH 3/8] Hugetlb: Migrating libhugetlbfs huge_below_4GB_normal_above

[Tarun Sahu]

Hi, 

Thanks for reviewing it.

On Dec 06 2022, Richard Palethorpe wrote:
> Hello,
> 
> Tarun Sahu <tsahu@linux.ibm.com> writes:
> 
> > Migrating the libhugetlbfs/testcases/huge_below_4GB_normal_above.c test
> >
> > Test Description: Designed to pick up a bug on ppc64 where
> > touches_hugepage_low_range() could give false positives because of the
> > peculiar (undefined) behaviour of << for large shifts
> >
> > Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
> > + *
> > + * Designed to pick up a bug on ppc64 where touches_hugepage_low_range()
> > + * could give false positives because of the peculiar (undefined)
> > + * behaviour of << for large shifts
> > + *
> > + * 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.
> 
> I guess the test is good insofar that I can tell. As with hugemmap13 it
> would be nice to have a reference to the bugfix though.
> 
> > +
> > +static struct tst_test test = {
> > +	.needs_root = 1,
> > +	.mntpoint = MNTPOINT,
> > +	.needs_hugetlbfs = 1,
> > +	.needs_tmpdir = 1,
> > +	.setup = setup,
> > +	.cleanup = cleanup,
> > +	.test_all = run_test,
> > +	.hugepages = {2, TST_NEEDS},
> 
> If we can find the bugfix commit then it can be referenced in the tags
> here.
>
Yeah, Will update the bug-fix references in v2
> -- 
> Thank you,
> Richard.
> 
> -- 
> Mailing list info: https://lists.linux.it/listinfo/ltp

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

[LTP] [PATCH 4/8] Hugetlb: Migrating libhugetlbfs icache-hygiene

[Tarun Sahu]

Migrating the libhugetlbfs/testcases/icache-hygiene.c test

Test Description: Older ppc64 kernels don't properly flush dcache to
icache before giving a cleared page to userspace.  With some exceedingly
hairy code, this attempts to test for this bug.

This test will never trigger (obviously) on machines with coherent
icache and dcache (including x86 and POWER5).  On any given run,
even on a buggy kernel there's a chance the bug won't trigger -
either because we don't get the same physical page back when we
remap, or because the icache happens to get flushed in the interim.

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

diff --git a/runtest/hugetlb b/runtest/hugetlb
index 796ebe7fa..0714ed34c 100644
--- a/runtest/hugetlb
+++ b/runtest/hugetlb
@@ -16,6 +16,7 @@ hugemmap11 hugemmap11
 hugemmap12 hugemmap12
 hugemmap13 hugemmap13
 hugemmap14 hugemmap14
+hugemmap15 hugemmap15
 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 3106579ce..d59b60fd4 100644
--- a/testcases/kernel/mem/.gitignore
+++ b/testcases/kernel/mem/.gitignore
@@ -15,6 +15,7 @@
 /hugetlb/hugemmap/hugemmap12
 /hugetlb/hugemmap/hugemmap13
 /hugetlb/hugemmap/hugemmap14
+/hugetlb/hugemmap/hugemmap15
 /hugetlb/hugeshmat/hugeshmat01
 /hugetlb/hugeshmat/hugeshmat02
 /hugetlb/hugeshmat/hugeshmat03
diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap15.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap15.c
new file mode 100644
index 000000000..8be4d194f
--- /dev/null
+++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap15.c
@@ -0,0 +1,239 @@
+// SPDX-License-Identifier: LGPL-2.1-or-later
+/*
+ * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
+ * Author: David Gibson & Adam Litke
+ */
+
+/*\
+ * [Description]
+ *
+ * Older ppc64 kernels don't properly flush dcache to icache before
+ * giving a cleared page to userspace.  With some exceedingly
+ * hairy code, this attempts to test for this bug.
+ *
+ * This test will never trigger (obviously) on machines with coherent
+ * icache and dcache (including x86 and POWER5).  On any given run,
+ * even on a buggy kernel there's a chance the bug won't trigger -
+ * either because we don't get the same physical page back when we
+ * remap, or because the icache happens to get flushed in the interim.
+ */
+
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <stdlib.h>
+#include <setjmp.h>
+#include <unistd.h>
+#include <signal.h>
+#include <sys/mman.h>
+#include <ucontext.h>
+#include <limits.h>
+#include <sys/param.h>
+#include <sys/types.h>
+
+#include "hugetlb.h"
+
+#define SUCC_JMP 1
+#define FAIL_JMP 2
+#define COPY_SIZE	128
+
+/* Seems to be enough to trigger reliably */
+#define NUM_REPETITIONS	64
+#define MNTPOINT "hugetlbfs/"
+static long hpage_size;
+static int  fd = -1;
+
+static void cacheflush(void *p)
+{
+#if defined(__powerpc__)
+	asm volatile("dcbst 0,%0; sync; icbi 0,%0; isync" : : "r"(p));
+#elif defined(__arm__) || defined(__aarch64__)
+	__clear_cache(p, p + COPY_SIZE);
+#else
+	(void)p;
+#endif
+}
+
+static void jumpfunc(int copy, void *p)
+{
+	/*
+	 * gcc bug workaround: if there is exactly one &&label
+	 * construct in the function, gcc assumes the computed goto
+	 * goes there, leading to the complete elision of the goto in
+	 * this case
+	 */
+	void *l = &&dummy;
+
+	l = &&jumplabel;
+
+	if (copy) {
+		memcpy(p, l, COPY_SIZE);
+		cacheflush(p);
+	}
+
+	goto *p;
+ dummy:
+	tst_res(TWARN, "unreachable?");
+
+ jumplabel:
+	return;
+}
+
+static sigjmp_buf sig_escape;
+static void *sig_expected;
+
+static void sig_handler(int signum, siginfo_t *si, void *uc)
+{
+#if defined(__powerpc__) || defined(__powerpc64__) || defined(__ia64__) || \
+	defined(__s390__) || defined(__s390x__) || defined(__sparc__) || \
+	defined(__aarch64__) || (defined(__riscv) && __riscv_xlen == 64)
+	/* On powerpc, ia64, s390 and Aarch64, 0 bytes are an illegal
+	 * instruction, so, if the icache is cleared properly, we SIGILL
+	 * as soon as we jump into the cleared page
+	 */
+	if (signum == SIGILL) {
+		tst_res(TINFO, "SIGILL at %p (sig_expected=%p)", si->si_addr,
+				sig_expected);
+		if (si->si_addr == sig_expected)
+			siglongjmp(sig_escape, SUCC_JMP);
+		siglongjmp(sig_escape, FAIL_JMP + SIGILL);
+	}
+#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__)
+	/* On x86, zero bytes form a valid instruction:
+	 *	add %al,(%eax)		(i386)
+	 * or	add %al,(%rax)		(x86_64)
+	 *
+	 * So, behaviour depends on the contents of [ER]AX, which in
+	 * turn depends on the details of code generation.  If [ER]AX
+	 * contains a valid pointer, we will execute the instruction
+	 * repeatedly until we run off that hugepage and get a SIGBUS
+	 * on the second, truncated page.  If [ER]AX does not contain
+	 * a valid pointer, we will SEGV on the first instruction in
+	 * the cleared page.  We check for both possibilities
+	 * below.
+	 *
+	 * On 32 bit ARM, zero bytes are interpreted as follows:
+	 *  andeq	r0, r0, r0	(ARM state, 4 bytes)
+	 *  movs	r0, r0		(Thumb state, 2 bytes)
+	 *
+	 * So, we only expect to run off the end of the huge page and
+	 * generate a SIGBUS.
+	 */
+	if (signum == SIGBUS) {
+		tst_res(TINFO, "SIGBUS at %p (sig_expected=%p)", si->si_addr,
+				sig_expected);
+		if (sig_expected
+		    && (PALIGN(sig_expected, hpage_size)
+			== si->si_addr)) {
+			siglongjmp(sig_escape, SUCC_JMP);
+		}
+		siglongjmp(sig_escape, FAIL_JMP + SIGBUS);
+	}
+#if defined(__x86_64__) || defined(__i386__)
+	if (signum == SIGSEGV) {
+#ifdef __x86_64__
+		void *pc = (void *)((ucontext_t *)uc)->uc_mcontext.gregs[REG_RIP];
+#else
+		void *pc = (void *)((ucontext_t *)uc)->uc_mcontext.gregs[REG_EIP];
+#endif
+		tst_res(TINFO, "SIGSEGV at %p, PC=%p (sig_expected=%p)",
+				si->si_addr, pc, sig_expected);
+		if (sig_expected == pc)
+			siglongjmp(sig_escape, SUCC_JMP);
+		siglongjmp(sig_escape, FAIL_JMP + SIGSEGV);
+	}
+#endif
+#else
+#error "Need to setup signal conditions for this arch"
+#endif
+}
+
+static int test_once(int fd)
+{
+	void *p, *q;
+
+	SAFE_FTRUNCATE(fd, 0);
+
+	switch (sigsetjmp(sig_escape, 1)) {
+	case SUCC_JMP:
+		sig_expected = NULL;
+		SAFE_FTRUNCATE(fd, 0);
+		return 0;
+	case FAIL_JMP + SIGILL:
+		tst_res(TFAIL, "SIGILL somewhere unexpected");
+		return -1;
+	case FAIL_JMP + SIGBUS:
+		tst_res(TFAIL, "SIGBUS somewhere unexpected");
+		return -1;
+	case FAIL_JMP + SIGSEGV:
+		tst_res(TFAIL, "SIGSEGV somewhere unexpected");
+		return -1;
+	default:
+		break;
+	}
+	p = SAFE_MMAP(NULL, 2*hpage_size, PROT_READ|PROT_WRITE|PROT_EXEC,
+		 MAP_SHARED, fd, 0);
+
+	SAFE_FTRUNCATE(fd, hpage_size);
+
+	q = p + hpage_size - COPY_SIZE;
+
+	jumpfunc(1, q);
+
+	SAFE_FTRUNCATE(fd, 0);
+	p = SAFE_MMAP(p, hpage_size, PROT_READ|PROT_WRITE|PROT_EXEC,
+		 MAP_SHARED|MAP_FIXED, fd, 0);
+
+	q = p + hpage_size - COPY_SIZE;
+	sig_expected = q;
+
+	jumpfunc(0, q); /* This should blow up */
+
+	tst_res(TFAIL, "icache unclean");
+	return -1;
+}
+
+static void run_test(void)
+{
+	int i;
+
+	struct sigaction sa = {
+		.sa_sigaction = sig_handler,
+		.sa_flags = SA_SIGINFO,
+	};
+
+	SAFE_SIGACTION(SIGILL, &sa, NULL);
+	SAFE_SIGACTION(SIGBUS, &sa, NULL);
+	SAFE_SIGACTION(SIGSEGV, &sa, NULL);
+
+	fd = tst_creat_unlinked(MNTPOINT, 0);
+
+	for (i = 0; i < NUM_REPETITIONS; i++)
+		if (test_once(fd))
+			goto cleanup;
+
+	tst_res(TPASS, "Successfully tested dcache to icache flush");
+cleanup:
+	SAFE_CLOSE(fd);
+}
+
+static void setup(void)
+{
+	hpage_size = SAFE_READ_MEMINFO("Hugepagesize:")*1024;
+}
+
+static void cleanup(void)
+{
+	if (fd > 0)
+		SAFE_CLOSE(fd);
+}
+
+static struct tst_test test = {
+	.needs_root = 1,
+	.mntpoint = MNTPOINT,
+	.needs_hugetlbfs = 1,
+	.needs_tmpdir = 1,
+	.setup = setup,
+	.cleanup = cleanup,
+	.test_all = run_test,
+	.hugepages = {3, TST_NEEDS},
+};
-- 
2.31.1


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

Re: [LTP] [PATCH 4/8] Hugetlb: Migrating libhugetlbfs icache-hygiene

[Richard Palethorpe]

Hello,

Tarun Sahu <tsahu@linux.ibm.com> writes:

> Migrating the libhugetlbfs/testcases/icache-hygiene.c test
>
> Test Description: Older ppc64 kernels don't properly flush dcache to
> icache before giving a cleared page to userspace.  With some exceedingly
> hairy code, this attempts to test for this bug.
>
> This test will never trigger (obviously) on machines with coherent
> icache and dcache (including x86 and POWER5).  On any given run,
> even on a buggy kernel there's a chance the bug won't trigger -
> either because we don't get the same physical page back when we
> remap, or because the icache happens to get flushed in the interim.

Compiling with Clang 15.0.5 on x86_64 and upstream kernel 6.0.9 in a KVM
VM the test fails:

sh-5.2# ./hugemmap15
[13712.044617] hugemmap15 (2118): drop_caches: 3
tst_hugepage.c:83: TINFO: 3 hugepage(s) reserved
tst_test.c:1560: TINFO: Timeout per run is 0h 00m 30s
hugemmap15.c:191: TFAIL: icache unclean

> +
> +static struct tst_test test = {
> +	.needs_root = 1,
> +	.mntpoint = MNTPOINT,
> +	.needs_hugetlbfs = 1,
> +	.needs_tmpdir = 1,
> +	.setup = setup,
> +	.cleanup = cleanup,
> +	.test_all = run_test,
> +	.hugepages = {3, TST_NEEDS},
> +};
> -- 
> 2.31.1

Again, it would be nice to have the git tag(s) of the fix commit(s) if
possible.

-- 
Thank you,
Richard.

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

Re: [LTP] [PATCH 4/8] Hugetlb: Migrating libhugetlbfs icache-hygiene

[Tarun Sahu]

Hi Richard,
Thanks for looking at it.

I am also trying to reproduce the same, In the meantime, I have found the
fix commit for this bug: https://lore.kernel.org/all/20051209032051.GA11744@localhost.localdomain/

I will update the tag in this and all tests moving forward,
Pardon me for missing such crucial details.

Thanks
Taurn
On Dec 12 2022, Richard Palethorpe wrote:
> Hello,
> 
> Tarun Sahu <tsahu@linux.ibm.com> writes:
> 
> > Migrating the libhugetlbfs/testcases/icache-hygiene.c test
> >
> > Test Description: Older ppc64 kernels don't properly flush dcache to
> > icache before giving a cleared page to userspace.  With some exceedingly
> > hairy code, this attempts to test for this bug.
> >
> > This test will never trigger (obviously) on machines with coherent
> > icache and dcache (including x86 and POWER5).  On any given run,
> > even on a buggy kernel there's a chance the bug won't trigger -
> > either because we don't get the same physical page back when we
> > remap, or because the icache happens to get flushed in the interim.
> 
> Compiling with Clang 15.0.5 on x86_64 and upstream kernel 6.0.9 in a KVM
> VM the test fails:
> 
> sh-5.2# ./hugemmap15
> [13712.044617] hugemmap15 (2118): drop_caches: 3
> tst_hugepage.c:83: TINFO: 3 hugepage(s) reserved
> tst_test.c:1560: TINFO: Timeout per run is 0h 00m 30s
> hugemmap15.c:191: TFAIL: icache unclean
> 
> > +
> > +static struct tst_test test = {
> > +	.needs_root = 1,
> > +	.mntpoint = MNTPOINT,
> > +	.needs_hugetlbfs = 1,
> > +	.needs_tmpdir = 1,
> > +	.setup = setup,
> > +	.cleanup = cleanup,
> > +	.test_all = run_test,
> > +	.hugepages = {3, TST_NEEDS},
> > +};
> > -- 
> > 2.31.1
> 
> Again, it would be nice to have the git tag(s) of the fix commit(s) if
> possible.
> 
> -- 
> Thank you,
> Richard.
> 
> -- 
> Mailing list info: https://lists.linux.it/listinfo/ltp

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

Re: [LTP] [PATCH 4/8] Hugetlb: Migrating libhugetlbfs icache-hygiene

[Tarun Sahu]

On Dec 13 2022, Tarun Sahu wrote:
Hi,

with clang (any version) it even fails on power (with/without VM).
while debugging with lldb, I found clang/llvm used an optmization which
caused goto *p to be ignored and it just jump to jumplabel. Tunrning off
the optimization makes the test work as expected.

I will post the v2 with change in Makefile for this test.

--- a/testcases/kernel/mem/hugetlb/hugemmap/Makefile
+++ b/testcases/kernel/mem/hugetlb/hugemmap/Makefile
@@ -8,4 +8,5 @@ include $(top_srcdir)/include/mk/testcases.mk
 include $(abs_srcdir)/../Makefile.inc
 include $(top_srcdir)/include/mk/generic_leaf_target.mk

+hugemmap15: CFLAGS+=-O0

Thanks
Tarun

> Hi Richard,
> Thanks for looking at it.
> 
> I am also trying to reproduce the same, In the meantime, I have found the
> fix commit for this bug: https://lore.kernel.org/all/20051209032051.GA11744@localhost.localdomain/
> 
> I will update the tag in this and all tests moving forward,
> Pardon me for missing such crucial details.
> 
> Thanks
> Taurn
> On Dec 12 2022, Richard Palethorpe wrote:
> > Hello,
> > 
> > Tarun Sahu <tsahu@linux.ibm.com> writes:
> > 
> > > Migrating the libhugetlbfs/testcases/icache-hygiene.c test
> > >
> > > Test Description: Older ppc64 kernels don't properly flush dcache to
> > > icache before giving a cleared page to userspace.  With some exceedingly
> > > hairy code, this attempts to test for this bug.
> > >
> > > This test will never trigger (obviously) on machines with coherent
> > > icache and dcache (including x86 and POWER5).  On any given run,
> > > even on a buggy kernel there's a chance the bug won't trigger -
> > > either because we don't get the same physical page back when we
> > > remap, or because the icache happens to get flushed in the interim.
> > 
> > Compiling with Clang 15.0.5 on x86_64 and upstream kernel 6.0.9 in a KVM
> > VM the test fails:
> > 
> > sh-5.2# ./hugemmap15
> > [13712.044617] hugemmap15 (2118): drop_caches: 3
> > tst_hugepage.c:83: TINFO: 3 hugepage(s) reserved
> > tst_test.c:1560: TINFO: Timeout per run is 0h 00m 30s
> > hugemmap15.c:191: TFAIL: icache unclean
> > 
> > > +
> > > +static struct tst_test test = {
> > > +	.needs_root = 1,
> > > +	.mntpoint = MNTPOINT,
> > > +	.needs_hugetlbfs = 1,
> > > +	.needs_tmpdir = 1,
> > > +	.setup = setup,
> > > +	.cleanup = cleanup,
> > > +	.test_all = run_test,
> > > +	.hugepages = {3, TST_NEEDS},
> > > +};
> > > -- 
> > > 2.31.1
> > 
> > Again, it would be nice to have the git tag(s) of the fix commit(s) if
> > possible.
> > 
> > -- 
> > Thank you,
> > Richard.
> > 
> > -- 
> > Mailing list info: https://lists.linux.it/listinfo/ltp
> 
> -- 
> Mailing list info: https://lists.linux.it/listinfo/ltp

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

[LTP] [PATCH 5/8] Hugetlb: Migrating libhugetlbfs madvise_reserve

[Tarun Sahu]

Migrating the libhugetlbfs/testcases/madvise_reserve.c test

Test Description: madvise() on some kernels can cause the reservation
counter to get corrupted. The problem is that the patches are allocated
for the reservation but not faulted in at the time of allocation. The
counters do not get updated and effectively "leak". This test
identifies whether the kernel is vulnerable to the problem or not.
It is fixed in kernel by 'commit f2deae9d4e70
("Remove implementation of readpage from the hugetlbfs_aops")'.

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

diff --git a/runtest/hugetlb b/runtest/hugetlb
index 0714ed34c..1691ce37d 100644
--- a/runtest/hugetlb
+++ b/runtest/hugetlb
@@ -17,6 +17,7 @@ hugemmap12 hugemmap12
 hugemmap13 hugemmap13
 hugemmap14 hugemmap14
 hugemmap15 hugemmap15
+hugemmap16 hugemmap16
 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 d59b60fd4..eb8e87c40 100644
--- a/testcases/kernel/mem/.gitignore
+++ b/testcases/kernel/mem/.gitignore
@@ -16,6 +16,7 @@
 /hugetlb/hugemmap/hugemmap13
 /hugetlb/hugemmap/hugemmap14
 /hugetlb/hugemmap/hugemmap15
+/hugetlb/hugemmap/hugemmap16
 /hugetlb/hugeshmat/hugeshmat01
 /hugetlb/hugeshmat/hugeshmat02
 /hugetlb/hugeshmat/hugeshmat03
diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap16.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap16.c
new file mode 100644
index 000000000..ea940e90c
--- /dev/null
+++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap16.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: LGPL-2.1-or-later
+/*
+ * Copyright (C) 2005-2006 IBM Corporation.
+ * Author: Eric B Munson and Mel Gorman
+ */
+
+/*\
+ * [Description]
+ *
+ * madvise() on some kernels can cause the reservation counter to get
+ * corrupted. The problem is that the patches are allocated
+ * for the reservation but not faulted in at the time of allocation. The
+ * counters do not get updated and effectively "leak". This test
+ * identifies whether the kernel is vulnerable to the problem or not.
+ * It is fixed in kernel by commit f2deae9d4e70793568ef9e85d227abb7bef5b622
+ */
+
+#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 MNTPOINT "hugetlbfs/"
+static int  fd = -1;
+static long hpage_size;
+
+static void run_test(void)
+{
+	void *p;
+	unsigned long initial_rsvd, map_rsvd, madvise_rsvd, end_rsvd;
+
+	fd = tst_creat_unlinked(MNTPOINT, 0);
+
+	initial_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
+	tst_res(TINFO, "Reserve count before map: %lu", initial_rsvd);
+
+	p = SAFE_MMAP(NULL, hpage_size, PROT_READ|PROT_WRITE, MAP_SHARED,
+		 fd, 0);
+	map_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
+	tst_res(TINFO, "Reserve count after map: %lu", map_rsvd);
+
+	if (madvise(p, hpage_size, MADV_WILLNEED) == -1)
+		tst_brk(TBROK|TERRNO, "madvise()");
+	madvise_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
+	tst_res(TINFO, "Reserve count after madvise: %lu", madvise_rsvd);
+
+	SAFE_MUNMAP(p, hpage_size);
+	SAFE_CLOSE(fd);
+	end_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
+	tst_res(TINFO, "Reserve count after close(): %lu", end_rsvd);
+
+	TST_EXP_EQ_LU(end_rsvd, initial_rsvd);
+}
+
+static void setup(void)
+{
+	hpage_size = SAFE_READ_MEMINFO("Hugepagesize:")*1024;
+}
+
+static void cleanup(void)
+{
+	if (fd >= 0)
+		SAFE_CLOSE(fd);
+}
+
+static struct tst_test test = {
+	.tags = (struct tst_tag[]) {
+		{"linux-git", "f2deae9d4e70"},
+		{}
+	},
+	.needs_root = 1,
+	.mntpoint = MNTPOINT,
+	.needs_hugetlbfs = 1,
+	.needs_tmpdir = 1,
+	.setup = setup,
+	.cleanup = cleanup,
+	.test_all = run_test,
+	.hugepages = {1, TST_NEEDS},
+};
-- 
2.31.1


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

Re: [LTP] [PATCH 5/8] Hugetlb: Migrating libhugetlbfs madvise_reserve

[Richard Palethorpe]

Hello,

Looks good,

Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>

Tarun Sahu <tsahu@linux.ibm.com> writes:

> Migrating the libhugetlbfs/testcases/madvise_reserve.c test
>
> Test Description: madvise() on some kernels can cause the reservation
> counter to get corrupted. The problem is that the patches are allocated
> for the reservation but not faulted in at the time of allocation. The
> counters do not get updated and effectively "leak". This test
> identifies whether the kernel is vulnerable to the problem or not.
> It is fixed in kernel by 'commit f2deae9d4e70
> ("Remove implementation of readpage from the hugetlbfs_aops")'.
>
> Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
> ---
>  runtest/hugetlb                               |  1 +
>  testcases/kernel/mem/.gitignore               |  1 +
>  .../kernel/mem/hugetlb/hugemmap/hugemmap16.c  | 83 +++++++++++++++++++
>  3 files changed, 85 insertions(+)
>  create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap16.c
>
> diff --git a/runtest/hugetlb b/runtest/hugetlb
> index 0714ed34c..1691ce37d 100644
> --- a/runtest/hugetlb
> +++ b/runtest/hugetlb
> @@ -17,6 +17,7 @@ hugemmap12 hugemmap12
>  hugemmap13 hugemmap13
>  hugemmap14 hugemmap14
>  hugemmap15 hugemmap15
> +hugemmap16 hugemmap16
>  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 d59b60fd4..eb8e87c40 100644
> --- a/testcases/kernel/mem/.gitignore
> +++ b/testcases/kernel/mem/.gitignore
> @@ -16,6 +16,7 @@
>  /hugetlb/hugemmap/hugemmap13
>  /hugetlb/hugemmap/hugemmap14
>  /hugetlb/hugemmap/hugemmap15
> +/hugetlb/hugemmap/hugemmap16
>  /hugetlb/hugeshmat/hugeshmat01
>  /hugetlb/hugeshmat/hugeshmat02
>  /hugetlb/hugeshmat/hugeshmat03
> diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap16.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap16.c
> new file mode 100644
> index 000000000..ea940e90c
> --- /dev/null
> +++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap16.c
> @@ -0,0 +1,83 @@
> +// SPDX-License-Identifier: LGPL-2.1-or-later
> +/*
> + * Copyright (C) 2005-2006 IBM Corporation.
> + * Author: Eric B Munson and Mel Gorman
> + */
> +
> +/*\
> + * [Description]
> + *
> + * madvise() on some kernels can cause the reservation counter to get
> + * corrupted. The problem is that the patches are allocated
> + * for the reservation but not faulted in at the time of allocation. The
> + * counters do not get updated and effectively "leak". This test
> + * identifies whether the kernel is vulnerable to the problem or not.
> + * It is fixed in kernel by commit f2deae9d4e70793568ef9e85d227abb7bef5b622
> + */
> +
> +#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 MNTPOINT "hugetlbfs/"
> +static int  fd = -1;
> +static long hpage_size;
> +
> +static void run_test(void)
> +{
> +	void *p;
> +	unsigned long initial_rsvd, map_rsvd, madvise_rsvd, end_rsvd;
> +
> +	fd = tst_creat_unlinked(MNTPOINT, 0);
> +
> +	initial_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
> +	tst_res(TINFO, "Reserve count before map: %lu", initial_rsvd);
> +
> +	p = SAFE_MMAP(NULL, hpage_size, PROT_READ|PROT_WRITE, MAP_SHARED,
> +		 fd, 0);
> +	map_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
> +	tst_res(TINFO, "Reserve count after map: %lu", map_rsvd);
> +
> +	if (madvise(p, hpage_size, MADV_WILLNEED) == -1)
> +		tst_brk(TBROK|TERRNO, "madvise()");
> +	madvise_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
> +	tst_res(TINFO, "Reserve count after madvise: %lu", madvise_rsvd);
> +
> +	SAFE_MUNMAP(p, hpage_size);
> +	SAFE_CLOSE(fd);
> +	end_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
> +	tst_res(TINFO, "Reserve count after close(): %lu", end_rsvd);
> +
> +	TST_EXP_EQ_LU(end_rsvd, initial_rsvd);
> +}
> +
> +static void setup(void)
> +{
> +	hpage_size = SAFE_READ_MEMINFO("Hugepagesize:")*1024;
> +}
> +
> +static void cleanup(void)
> +{
> +	if (fd >= 0)
> +		SAFE_CLOSE(fd);
> +}
> +
> +static struct tst_test test = {
> +	.tags = (struct tst_tag[]) {
> +		{"linux-git", "f2deae9d4e70"},
> +		{}
> +	},
> +	.needs_root = 1,
> +	.mntpoint = MNTPOINT,
> +	.needs_hugetlbfs = 1,
> +	.needs_tmpdir = 1,
> +	.setup = setup,
> +	.cleanup = cleanup,
> +	.test_all = run_test,
> +	.hugepages = {1, TST_NEEDS},
> +};
> -- 
> 2.31.1


-- 
Thank you,
Richard.

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

[LTP] [PATCH 6/8] Hugetlb: Migrating libhugetlbfs map_high_truncate_2

[Tarun Sahu]

Migrating the libhugetlbfs/testcases/map_high_truncate_2.c test

Test Description: At one stage, a misconversion of hugetlb_vmtruncate_list
to a prio_tree meant that on 32-bit machines, certain combinations of
mapping and truncations could truncate incorrect pages, or
overwrite pmds from other VMAs, triggering BUG_ON()s or other
wierdness.

Test adapted from an example by Kenneth Chen <kenneth.w.chen@intel.com>

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.

The kernel bug in question was fixed with
'commit 856fc2950555 ("[PATCH] hugetlb: fix prio_tree unit")'.

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

diff --git a/runtest/hugetlb b/runtest/hugetlb
index 1691ce37d..5fac3481c 100644
--- a/runtest/hugetlb
+++ b/runtest/hugetlb
@@ -18,6 +18,7 @@ hugemmap13 hugemmap13
 hugemmap14 hugemmap14
 hugemmap15 hugemmap15
 hugemmap16 hugemmap16
+hugemmap17 hugemmap17
 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 eb8e87c40..6aa54f902 100644
--- a/testcases/kernel/mem/.gitignore
+++ b/testcases/kernel/mem/.gitignore
@@ -17,6 +17,7 @@
 /hugetlb/hugemmap/hugemmap14
 /hugetlb/hugemmap/hugemmap15
 /hugetlb/hugemmap/hugemmap16
+/hugetlb/hugemmap/hugemmap17
 /hugetlb/hugeshmat/hugeshmat01
 /hugetlb/hugeshmat/hugeshmat02
 /hugetlb/hugeshmat/hugeshmat03
diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap17.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap17.c
new file mode 100644
index 000000000..1815765d2
--- /dev/null
+++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap17.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: LGPL-2.1-or-later
+/*
+ * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
+ * Author: David Gibson & Adam Litke
+ */
+
+/*\
+ * [Descriptiom]
+ *
+ * At one stage, a misconversion of hugetlb_vmtruncate_list to a prio_tree
+ * meant that on 32-bit machines, certain combinations of mapping and
+ * truncations could truncate incorrect pages, or overwrite pmds from
+ * other VMAs, triggering BUG_ON()s or other wierdness.
+ *
+ * Test adapted from an example by Kenneth Chen <kenneth.w.chen@intel.com>
+ *
+ * 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.
+ *
+ * The kernel bug in question was fixed with commit
+ * 856fc29505556cf263f3dcda2533cf3766c14ab6.
+ */
+
+#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 MNTPOINT "hugetlbfs/"
+#define MAP_LENGTH	(4UL * hpage_size)
+#if defined(__s390__) && __WORDSIZE == 32
+#define TRUNCATE_POINT 0x20000000UL
+#else
+#define TRUNCATE_POINT 0x60000000UL
+#endif
+#define HIGH_ADDR	0xa0000000UL
+#define FOURGIG		((off64_t)0x100000000ULL)
+
+static unsigned long hpage_size;
+static int  fd = -1;
+
+static void run_test(void)
+{
+	char *p, *q;
+	unsigned long i;
+
+	p = SAFE_MMAP(0, MAP_LENGTH + TRUNCATE_POINT, PROT_READ | PROT_WRITE,
+		 MAP_PRIVATE | MAP_NORESERVE, fd, 0);
+
+	SAFE_MUNMAP(p, MAP_LENGTH + TRUNCATE_POINT);
+
+	q = SAFE_MMAP((void *)HIGH_ADDR, MAP_LENGTH, PROT_READ | PROT_WRITE,
+		 MAP_PRIVATE, fd, 0);
+	tst_res(TINFO, "High map at %p", q);
+
+	for (i = 0; i < MAP_LENGTH; i += hpage_size)
+		q[i] = 1;
+
+	SAFE_FTRUNCATE(fd, TRUNCATE_POINT);
+
+	if (q[0] != 1)
+		tst_res(TFAIL, "data mismatch");
+	else
+		tst_res(TPASS, "Successful");
+
+	SAFE_MUNMAP(q, MAP_LENGTH);
+}
+
+static void setup(void)
+{
+	hpage_size = SAFE_READ_MEMINFO("Hugepagesize:")*1024;
+
+	if (hpage_size > TRUNCATE_POINT)
+		tst_brk(TCONF, "Huge page size is too large");
+	if (TRUNCATE_POINT % hpage_size)
+		tst_brk(TCONF, "Truncation point is not aligned to huge page size");
+	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", "856fc2950555"},
+		{}
+	},
+	.needs_root = 1,
+	.mntpoint = MNTPOINT,
+	.needs_hugetlbfs = 1,
+	.setup = setup,
+	.cleanup = cleanup,
+	.test_all = run_test,
+	.hugepages = {4, TST_NEEDS},
+};
-- 
2.31.1


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

Re: [LTP] [PATCH 6/8] Hugetlb: Migrating libhugetlbfs map_high_truncate_2

[Richard Palethorpe]

Hello,

Tarun Sahu <tsahu@linux.ibm.com> writes:

> Migrating the libhugetlbfs/testcases/map_high_truncate_2.c test
>
> Test Description: At one stage, a misconversion of hugetlb_vmtruncate_list
> to a prio_tree meant that on 32-bit machines, certain combinations of
> mapping and truncations could truncate incorrect pages, or
> overwrite pmds from other VMAs, triggering BUG_ON()s or other
> wierdness.
>
> Test adapted from an example by Kenneth Chen <kenneth.w.chen@intel.com>
>
> 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.
>
> The kernel bug in question was fixed with
> 'commit 856fc2950555 ("[PATCH] hugetlb: fix prio_tree unit")'.
>
> Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>

-- 
Thank you,
Richard.

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

[LTP] [PATCH 7/8] Hugetlb: Migrating libhugetlbfs misalign

[Tarun Sahu]

Migrating the libhugetlbfs/testcases/misalign.c test

Test Description: Just as normal mmap()s can't have an address, length or
offset which is not page aligned, so hugepage mmap()s can't have an
address, length or offset with is not hugepage aligned.

However, from time to time when the various mmap() /
get_unmapped_area() paths are updated, somebody misses one of the
necessary checks for the hugepage paths.  This testcase ensures
that attempted hugepage mappings with parameters which are not
correctly hugepage aligned are rejected.

However starting with 3.10-rc1, length passed in mmap() doesn't need
to be aligned because 'commit af73e4d9506d
("hugetlbfs: fix mmap failure in unaligned size request")' added ALIGN()
to kernel side, in mmap_pgoff(), when mapping huge page files.

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

diff --git a/runtest/hugetlb b/runtest/hugetlb
index 5fac3481c..de76cdaf2 100644
--- a/runtest/hugetlb
+++ b/runtest/hugetlb
@@ -19,6 +19,7 @@ hugemmap14 hugemmap14
 hugemmap15 hugemmap15
 hugemmap16 hugemmap16
 hugemmap17 hugemmap17
+hugemmap18 hugemmap18
 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 6aa54f902..daee70586 100644
--- a/testcases/kernel/mem/.gitignore
+++ b/testcases/kernel/mem/.gitignore
@@ -18,6 +18,7 @@
 /hugetlb/hugemmap/hugemmap15
 /hugetlb/hugemmap/hugemmap16
 /hugetlb/hugemmap/hugemmap17
+/hugetlb/hugemmap/hugemmap18
 /hugetlb/hugeshmat/hugeshmat01
 /hugetlb/hugeshmat/hugeshmat02
 /hugetlb/hugeshmat/hugeshmat03
diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap18.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap18.c
new file mode 100644
index 000000000..607072937
--- /dev/null
+++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap18.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: LGPL-2.1-or-later
+/*
+ * Copyright (C) 2005-2007 David Gibson & Adam Litke, IBM Corporation.
+ * Author: David Gibson & Adam Litke
+ */
+
+/*\
+ * [Description]
+ *
+ * Just as normal mmap()s can't have an address, length or offset which
+ * is not page aligned, so hugepage mmap()s can't have an address, length
+ * or offset with is not hugepage aligned.
+ *
+ * However, from time to time when the various mmap() /
+ * get_unmapped_area() paths are updated, somebody misses one of the
+ * necessary checks for the hugepage paths.  This testcase ensures
+ * that attempted hugepage mappings with parameters which are not
+ * correctly hugepage aligned are rejected.
+ *
+ * However starting with 3.10-rc1, length passed in mmap() doesn't need
+ * to be aligned because commit af73e4d9506d3b797509f3c030e7dcd554f7d9c4
+ * added ALIGN() to kernel side, in mmap_pgoff(), when mapping huge page
+ * files.
+ */
+
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/mman.h>
+
+#include "hugetlb.h"
+
+#define MNTPOINT "hugetlbfs/"
+static long hpage_size;
+static int  fd = -1;
+static long page_size;
+
+static void run_test(void)
+{
+	void *p, *q;
+
+	/*
+	 * First see what an ok mapping looks like, as a basis for our
+	 * bad addresses and so forth
+	 */
+	p = mmap(NULL, hpage_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
+	if (p == MAP_FAILED) {
+		tst_res(TFAIL|TERRNO, "mmap() without hint failed");
+		return;
+	}
+	if (((unsigned long)p % hpage_size) != 0) {
+		tst_res(TFAIL, "mmap() without hint at misaligned address");
+		goto cleanup1;
+	}
+
+	tst_res(TINFO, "Mapped at %p, length 0x%lx", p, hpage_size);
+
+	SAFE_MUNMAP(p, hpage_size);
+
+	/* 1) Try a misaligned hint address */
+	q = mmap(p + page_size, hpage_size, PROT_READ|PROT_WRITE,
+		 MAP_PRIVATE, fd, 0);
+	if (q == MAP_FAILED) {
+		/* Bad hint shouldn't fail, just ignore the hint */
+		tst_res(TFAIL|TERRNO, "mmap() with hint failed");
+		return;
+	}
+	if (((unsigned long)q % hpage_size) != 0) {
+		tst_res(TFAIL, "mmap() with hint at misaligned address");
+		goto cleanup2;
+	}
+	SAFE_MUNMAP(q, hpage_size);
+
+	/* 2) Try a misaligned address with MAP_FIXED */
+	q = mmap(p + page_size, hpage_size, PROT_READ|PROT_WRITE,
+		 MAP_PRIVATE|MAP_FIXED, fd, 0);
+	if (q != MAP_FAILED) {
+		tst_res(TFAIL, "mmap() MAP_FIXED at misaligned address succeeded");
+		goto cleanup2;
+	}
+
+	/* 3) Try a misaligned length */
+	q = mmap(NULL, page_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
+	if (q == MAP_FAILED) {
+		tst_res(TFAIL, "mmap() with misaligned length 0x%lx failed",
+			page_size);
+		return;
+	}
+	SAFE_MUNMAP(q, hpage_size);
+
+	/* 4) Try a misaligned length with MAP_FIXED */
+	q = mmap(p, page_size, PROT_READ|PROT_WRITE,
+			MAP_PRIVATE|MAP_FIXED, fd, 0);
+	if (q == MAP_FAILED) {
+		tst_res(TFAIL, "mmap() MAP_FIXED with misaligned length 0x%lx "
+			"failed", page_size);
+		return;
+	}
+	SAFE_MUNMAP(q, hpage_size);
+
+	/* 5) Try a misaligned offset */
+	q = mmap(NULL, hpage_size, PROT_READ|PROT_WRITE,
+		 MAP_PRIVATE, fd, page_size);
+	if (q != MAP_FAILED) {
+		tst_res(TFAIL, "mmap() with misaligned offset 0x%lx succeeded",
+		     page_size);
+		goto cleanup2;
+	}
+
+	/* 6) Try a misaligned offset with MAP_FIXED*/
+	q = mmap(p, hpage_size, PROT_READ|PROT_WRITE,
+		 MAP_PRIVATE|MAP_FIXED, fd, page_size);
+	if (q != MAP_FAILED) {
+		tst_res(TFAIL, "mmap() MAP_FIXED with misaligned offset 0x%lx succeeded",
+		     page_size);
+		goto cleanup2;
+	}
+
+	tst_res(TPASS, "mmap worked as expected with misaligned addr and length");
+	return;
+cleanup2:
+	SAFE_MUNMAP(q, hpage_size);
+	return;
+cleanup1:
+	SAFE_MUNMAP(p, hpage_size);
+}
+
+static void setup(void)
+{
+	hpage_size = SAFE_READ_MEMINFO("Hugepagesize:")*1024;
+	page_size = getpagesize();
+	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", "af73e4d9506d"},
+		{}
+	},
+	.needs_root = 1,
+	.mntpoint = MNTPOINT,
+	.needs_hugetlbfs = 1,
+	.setup = setup,
+	.cleanup = cleanup,
+	.test_all = run_test,
+	.hugepages = {4, TST_NEEDS},
+};
-- 
2.31.1


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

Re: [LTP] [PATCH 7/8] Hugetlb: Migrating libhugetlbfs misalign

[Richard Palethorpe]

Tarun Sahu <tsahu@linux.ibm.com> writes:

> Migrating the libhugetlbfs/testcases/misalign.c test
>
> Test Description: Just as normal mmap()s can't have an address, length or
> offset which is not page aligned, so hugepage mmap()s can't have an
> address, length or offset with is not hugepage aligned.
>
> However, from time to time when the various mmap() /
> get_unmapped_area() paths are updated, somebody misses one of the
> necessary checks for the hugepage paths.  This testcase ensures
> that attempted hugepage mappings with parameters which are not
> correctly hugepage aligned are rejected.
>
> However starting with 3.10-rc1, length passed in mmap() doesn't need
> to be aligned because 'commit af73e4d9506d
> ("hugetlbfs: fix mmap failure in unaligned size request")' added ALIGN()
> to kernel side, in mmap_pgoff(), when mapping huge page files.
>
> Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>

-- 
Thank you,
Richard.

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

[LTP] [PATCH 8/8] Hugetlb: Migrating libhugetlbfs misaligned_offset

[Tarun Sahu]

Migrating the libhugetlbfs/testcases/misaligned_offset.c test

Test Name: Misaligned offset

Test Description: At one stage, a misconversion of hugetlb_vmtruncate_list
to a prio_tree meant that on 32-bit machines, truncates at or above 4GB
could truncate lower pages, resulting in BUG_ON()s.

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.

The kernel bug in question was fixed with
'commit 856fc2950555 ("[PATCH] hugetlb: fix prio_tree unit")'.

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

diff --git a/runtest/hugetlb b/runtest/hugetlb
index de76cdaf2..4da1525a7 100644
--- a/runtest/hugetlb
+++ b/runtest/hugetlb
@@ -20,6 +20,7 @@ hugemmap15 hugemmap15
 hugemmap16 hugemmap16
 hugemmap17 hugemmap17
 hugemmap18 hugemmap18
+hugemmap19 hugemmap19
 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 daee70586..b6b3e5ddd 100644
--- a/testcases/kernel/mem/.gitignore
+++ b/testcases/kernel/mem/.gitignore
@@ -19,6 +19,7 @@
 /hugetlb/hugemmap/hugemmap16
 /hugetlb/hugemmap/hugemmap17
 /hugetlb/hugemmap/hugemmap18
+/hugetlb/hugemmap/hugemmap19
 /hugetlb/hugeshmat/hugeshmat01
 /hugetlb/hugeshmat/hugeshmat02
 /hugetlb/hugeshmat/hugeshmat03
diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap19.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap19.c
new file mode 100644
index 000000000..c5b29a701
--- /dev/null
+++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap19.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: LGPL-2.1-or-later
+/*
+ * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
+ * Copyright (C) 2006 Hugh Dickins <hugh@veritas.com>
+ * Author: David Gibson & Adam Litke
+ */
+
+/*\
+ * [Descripiton]
+ *
+ * At one stage, a misconversion of hugetlb_vmtruncate_list to a
+ * prio_tree meant that on 32-bit machines, truncates at or above 4GB
+ * could truncate lower pages, resulting in BUG_ON()s.
+ *
+ * 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.
+ *
+ * The kernel bug in question was fixed with commit
+ * 856fc29505556cf263f3dcda2533cf3766c14ab6.
+ */
+
+#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 RANDOM_CONSTANT	0x1234ABCD
+#define MNTPOINT "hugetlbfs/"
+static int page_size;
+static long hpage_size;
+static int  fd = -1;
+
+static void run_test(void)
+{
+	off_t buggy_offset;
+	void *p, *q;
+	volatile int *pi;
+	int err;
+
+	/*
+	 * First, we make a 2 page sane hugepage mapping.  Then we
+	 * memset() it to ensure that the ptes are instantiated for
+	 * it.  Then we attempt to replace the second half of the map
+	 * with one at a bogus offset.  We leave the first page of
+	 * sane mapping in place to ensure that the corresponding
+	 * pud/pmd/whatever entries aren't cleaned away.  It's those
+	 * bad entries which can trigger bad_pud() checks if the
+	 * backout path for the bogus mapping is buggy, which it was
+	 * in some kernels.
+	 */
+	tst_res(TINFO, "Initial free hugepages: %lu",
+		SAFE_READ_MEMINFO(MEMINFO_HPAGE_FREE));
+
+	/* First get arena of three hpages size, at file offset 4GB */
+	p = SAFE_MMAP(NULL, 2*hpage_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
+
+	tst_res(TINFO, "After Mapping reference map, Free hugepages: %lu",
+		SAFE_READ_MEMINFO(MEMINFO_HPAGE_FREE));
+	tst_res(TINFO, "Mapped Address Range: %p-%p", p, p+2*hpage_size-1);
+
+	memset(p, 0, 2*hpage_size);
+	pi = p;
+	*pi = RANDOM_CONSTANT;
+
+	tst_res(TINFO, "After instantiate the pages, Free hugepages: %lu",
+		   SAFE_READ_MEMINFO(MEMINFO_HPAGE_FREE));
+
+	/*
+	 * Toggle the permissions on the first page.  This forces TLB
+	 * entries (including hash page table on powerpc) to be
+	 * flushed, so that the page tables must be accessed for the
+	 * test further down.  In the buggy case, those page tables
+	 * can get thrown away by a pud_clear()
+	 */
+	err = mprotect(p, hpage_size, PROT_READ);
+	if (err)
+		tst_brk(TBROK|TERRNO, "mprotect(%p, 0x%lx, PROT_READ)", p, hpage_size);
+
+	/* Replace top hpage by hpage mapping at confusing file offset */
+	buggy_offset = page_size;
+	tst_res(TINFO, "Replacing map at %p with map from offset 0x%lx...",
+	       p + hpage_size, (unsigned long)buggy_offset);
+	q = mmap(p + hpage_size, hpage_size, PROT_READ|PROT_WRITE,
+		 MAP_FIXED|MAP_PRIVATE, fd, buggy_offset);
+	if (q != MAP_FAILED) {
+		tst_res(TFAIL|TERRNO, "bogus offset mmap() succeeded at %p", q);
+		goto cleanup;
+	}
+	if (errno != EINVAL) {
+		tst_res(TFAIL|TERRNO, "bogus mmap() failed should be \"%s\" but it is",
+		     tst_strerrno(EINVAL));
+		goto cleanup;
+	}
+
+	tst_res(TINFO, "After Mapping with buggy offset, Free hugepages: %lu",
+		SAFE_READ_MEMINFO(MEMINFO_HPAGE_FREE));
+
+	if (*pi != RANDOM_CONSTANT) {
+		tst_res(TFAIL, "Pre-existing mapping clobbered: %x instead of %x",
+		     *pi, RANDOM_CONSTANT);
+		goto cleanup;
+	}
+
+	/*
+	 * The real test is whether we got a bad_pud() or similar
+	 * during the run.  The check above, combined with the earlier
+	 * mprotect()s to flush the TLB are supposed to catch it, but
+	 * it's hard to be certain.  Once bad_pud() is called
+	 * behaviour can be very strange.
+	 */
+
+	tst_res(TPASS, "Successful but inconclusive");
+cleanup:
+	SAFE_MUNMAP(p, 2*hpage_size);
+}
+
+static void setup(void)
+{
+	page_size = getpagesize();
+	hpage_size = SAFE_READ_MEMINFO("Hugepagesize:")*1024;
+	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", "856fc2950555"},
+		{}
+	},
+	.needs_root = 1,
+	.mntpoint = MNTPOINT,
+	.needs_hugetlbfs = 1,
+	.setup = setup,
+	.cleanup = cleanup,
+	.test_all = run_test,
+	.hugepages = {4, TST_NEEDS},
+};
-- 
2.31.1


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

Re: [LTP] [PATCH 8/8] Hugetlb: Migrating libhugetlbfs misaligned_offset

[Richard Palethorpe]

Tarun Sahu <tsahu@linux.ibm.com> writes:

> Migrating the libhugetlbfs/testcases/misaligned_offset.c test
>
> Test Name: Misaligned offset
>
> Test Description: At one stage, a misconversion of hugetlb_vmtruncate_list
> to a prio_tree meant that on 32-bit machines, truncates at or above 4GB
> could truncate lower pages, resulting in BUG_ON()s.
>
> 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.
>
> The kernel bug in question was fixed with
> 'commit 856fc2950555 ("[PATCH] hugetlb: fix prio_tree unit")'.
>
> Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>


-- 
Thank you,
Richard.

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

Re: [LTP] [PATCH 0/8][PART 3] Hugetlb:Migrating the libhugetlbfs tests

[Richard Palethorpe]

Hello,

Setting the rest of this patch serious to "changes requested" in
patchwork. EVen though I have added reviewed tags to most of the tests,
I don't want to merge them out of sequence.

Also please assume that any comments that were made about previous tests
may also apply to those left. I did not check these very carefully.

-- 
Thank you,
Richard.

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

Re: [LTP] [PATCH 0/8][PART 3] Hugetlb:Migrating the libhugetlbfs tests

[Tarun Sahu]

On Dec 12 2022, Richard Palethorpe wrote:
> Hello,
> 
> Setting the rest of this patch serious to "changes requested" in
> patchwork. EVen though I have added reviewed tags to most of the tests,
> I don't want to merge them out of sequence.
> 
> Also please assume that any comments that were made about previous tests
> may also apply to those left. I did not check these very carefully.
> 
Thanks, for reviewing it, Richard.
Sure, Will update and post updated version.

Thanks
Tarun

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

[LTP] [PATCH v5 0/7][PART 2] Hugetlb:Migrating the libhugetlbfs tests

[Tarun Sahu]

Hi,
This patch series is in continuation to first part [1]
This series include 5 more tests taken from libhugetlbfs.

Background:
Libhugetlbfs is not being maintained actively, and some distro is dropping
support for it. There are some tests that are good for testing hugetlb
functionality in kernel. These patches include tests from libhugetlbfs.

ref:
 1. https://lore.kernel.org/all/20221104162511.28658-1-tsahu@linux.ibm.com/

v4 -> v5
	1. PATCH[1/7] Removed the srand() call from tst_creat_unlinked.
	2. PATCH[2/7] Reworked on the code. Removed the macro based
	condition check. Added condition check for each function call
	and created a new function for loop action.

v3 -> v4
	1. Removing redundant access call to check if file already exists.
	and removing the retry path, as the case is very rare.

v2 -> v3
	1. Changed from setjmp/longjmp logic to check/return logic in
	hugemmap10.c
	2. Added a new patch to create support for custom flags in
	tst_creat_unlinked api.
	3. Added patch to add safe macros for posix_fadvise call.
	4. Updated coding asthetics.
	5. Added description along with the line of failure in hugemmap10.c

v1 -> v2
	1. Fixed comments

Tarun Sahu (7):
  Hugetlb: Add new argument flags in tst_creat_unlinked
  Hugetlb: Migrating libhugetlbfs counters
  Hugetlb: Migrating libhugetlbfs directio
  Hugetlb: Safe macro for posix_fadvise call
  Hugetlb: Migrating libhugetlbfs fadvise_reserve
  Hugetlb: Migrating libhugetlbfs fallocate_align
  Hugetlb: Migrating libhugetlbfs fallocate_basic

 include/tst_safe_macros.h                     |  17 +
 include/tst_test.h                            |   2 +-
 lib/tst_test.c                                |  16 +-
 runtest/hugetlb                               |   6 +
 testcases/kernel/mem/.gitignore               |   5 +
 .../kernel/mem/hugetlb/hugefallocate/Makefile |  10 +
 .../hugetlb/hugefallocate/hugefallocate01.c   | 169 +++++++
 .../hugetlb/hugefallocate/hugefallocate02.c   |  90 ++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap07.c  |   2 +-
 .../kernel/mem/hugetlb/hugemmap/hugemmap08.c  |   2 +-
 .../kernel/mem/hugetlb/hugemmap/hugemmap09.c  |   2 +-
 .../kernel/mem/hugetlb/hugemmap/hugemmap10.c  | 462 ++++++++++++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap11.c  |  87 ++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap12.c  |  84 ++++
 14 files changed, 946 insertions(+), 8 deletions(-)
 create mode 100644 testcases/kernel/mem/hugetlb/hugefallocate/Makefile
 create mode 100644 testcases/kernel/mem/hugetlb/hugefallocate/hugefallocate01.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugefallocate/hugefallocate02.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap10.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap11.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap12.c

-- 
2.31.1


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

[LTP] [PATCH 0/8][PART 3] Hugetlb:Migrating the libhugetlbfs tests

[Tarun Sahu]

Hi,
This patch series is in continuation to part [1] and part [2]
This series include 8 more tests taken from libhugetlbfs.

Background:
Libhugetlbfs is not being maintained actively, and some distro is dropping
support for it. There are some tests that are good for testing hugetlb
functionality in kernel. These patches include tests from libhugetlbfs.

ref:
 1. https://lore.kernel.org/all/20221104162511.28658-1-tsahu@linux.ibm.com/
 2. https://lore.kernel.org/all/20221120191533.164848-1-tsahu@linux.ibm.com/

Tarun Sahu (8):
  Hugetlb: Migrating libhugetlbfs fork-cow
  Hugetlb: Migrating libhugetlbfs huge_at_4GB_normal_below
  Hugetlb: Migrating libhugetlbfs huge_below_4GB_normal_above
  Hugetlb: Migrating libhugetlbfs icache-hygiene
  Hugetlb: Migrating libhugetlbfs madvise_reserve
  Hugetlb: Migrating libhugetlbfs map_high_truncate_2
  Hugetlb: Migrating libhugetlbfs misalign
  Hugetlb: Migrating libhugetlbfs misaligned_offset

 runtest/hugetlb                               |   9 +
 testcases/kernel/mem/.gitignore               |   8 +
 .../kernel/mem/hugetlb/hugefork/Makefile      |  10 +
 .../kernel/mem/hugetlb/hugefork/hugefork01.c  | 108 ++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap13.c  | 122 +++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap14.c  | 156 ++++++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap15.c  | 239 ++++++++++++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap16.c  |  83 ++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap17.c  | 103 ++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap18.c  | 153 +++++++++++
 .../kernel/mem/hugetlb/hugemmap/hugemmap19.c  | 147 +++++++++++
 11 files changed, 1138 insertions(+)
 create mode 100644 testcases/kernel/mem/hugetlb/hugefork/Makefile
 create mode 100644 testcases/kernel/mem/hugetlb/hugefork/hugefork01.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap13.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap14.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap15.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap16.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap17.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap18.c
 create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap19.c

-- 
2.31.1


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

[LTP] [PATCH 3/8] Hugetlb: Migrating libhugetlbfs huge_below_4GB_normal_above

[Tarun Sahu]

Migrating the libhugetlbfs/testcases/huge_below_4GB_normal_above.c test

Test Description: Designed to pick up a bug on ppc64 where
touches_hugepage_low_range() could give false positives because of the
peculiar (undefined) behaviour of << for large shifts

Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
---
 runtest/hugetlb                               |   1 +
 testcases/kernel/mem/.gitignore               |   1 +
 .../kernel/mem/hugetlb/hugemmap/hugemmap14.c  | 156 ++++++++++++++++++
 3 files changed, 158 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..8ccd141f8
--- /dev/null
+++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap14.c
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: LGPL-2.1-or-later
+/*
+ * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
+ * Author: David Gibson & Adam Litke
+ */
+
+/*\
+ * [Description]
+ *
+ * Designed to pick up a bug on ppc64 where touches_hugepage_low_range()
+ * could give false positives because of the peculiar (undefined)
+ * behaviour of << for large shifts
+ *
+ * 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 = {
+	.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