From: Tarun Sahu <tsahu@linux.ibm.com>
To: ltp@lists.linux.it
Cc: geetika@linux.ibm.com, sbhat@linux.ibm.com,
aneesh.kumar@linux.ibm.com, vaibhav@linux.ibm.com
Subject: [LTP] [PATCH 1/8] Hugetlb: Migrating libhugetlbfs fork-cow
Date: Thu, 1 Dec 2022 17:32:41 +0530 [thread overview]
Message-ID: <20221201120248.139396-2-tsahu@linux.ibm.com> (raw)
In-Reply-To: <20221201120248.139396-1-tsahu@linux.ibm.com>
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
next prev parent reply other threads:[~2022-12-01 12:03 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-20 19:15 [LTP] [PATCH v5 0/7][PART 2] Hugetlb:Migrating the libhugetlbfs tests Tarun Sahu
2022-11-20 19:15 ` [LTP] [PATCH v5 1/7] Hugetlb: Add new argument flags in tst_creat_unlinked Tarun Sahu
2022-11-24 11:55 ` Cyril Hrubis
2022-11-20 19:15 ` [LTP] [PATCH v5 2/7] Hugetlb: Migrating libhugetlbfs counters Tarun Sahu
2022-11-20 19:15 ` [LTP] [PATCH v5 3/7] Hugetlb: Migrating libhugetlbfs directio Tarun Sahu
2022-11-20 19:15 ` [LTP] [PATCH v5 4/7] Hugetlb: Safe macro for posix_fadvise call Tarun Sahu
2022-11-24 11:59 ` Cyril Hrubis
2022-11-25 17:34 ` Tarun Sahu
2022-11-25 18:59 ` Cyril Hrubis
2022-11-20 19:15 ` [LTP] [PATCH v5 5/7] Hugetlb: Migrating libhugetlbfs fadvise_reserve Tarun Sahu
2022-11-20 19:15 ` [LTP] [PATCH v5 6/7] Hugetlb: Migrating libhugetlbfs fallocate_align Tarun Sahu
2022-11-24 14:51 ` Cyril Hrubis
2022-11-20 19:15 ` [LTP] [PATCH v5 7/7] Hugetlb: Migrating libhugetlbfs fallocate_basic Tarun Sahu
2022-11-25 22:37 ` [LTP] [PATCH v6 1/2] Hugetlb: Safe macro for posix_fadvise call Tarun Sahu
2022-11-25 22:37 ` [LTP] [PATCH v6 2/2] Hugetlb: Migrating libhugetlbfs fadvise_reserve Tarun Sahu
2022-11-29 16:21 ` [LTP] [PATCH v6 1/2] Hugetlb: Safe macro for posix_fadvise call Cyril Hrubis
2022-12-01 8:35 ` Tarun Sahu
2022-12-01 12:02 ` [LTP] [PATCH 0/8][PART 3] Hugetlb:Migrating the libhugetlbfs tests Tarun Sahu
2022-12-01 12:02 ` Tarun Sahu [this message]
2022-12-01 12:02 ` [LTP] [PATCH 2/8] Hugetlb: Migrating libhugetlbfs huge_at_4GB_normal_below Tarun Sahu
2022-12-01 12:02 ` [LTP] [PATCH 3/8] Hugetlb: Migrating libhugetlbfs huge_below_4GB_normal_above Tarun Sahu
2022-12-01 12:02 ` [LTP] [PATCH 4/8] Hugetlb: Migrating libhugetlbfs icache-hygiene Tarun Sahu
2022-12-01 12:02 ` [LTP] [PATCH 5/8] Hugetlb: Migrating libhugetlbfs madvise_reserve Tarun Sahu
2022-12-01 12:02 ` [LTP] [PATCH 6/8] Hugetlb: Migrating libhugetlbfs map_high_truncate_2 Tarun Sahu
2022-12-01 12:02 ` [LTP] [PATCH 7/8] Hugetlb: Migrating libhugetlbfs misalign Tarun Sahu
2022-12-01 12:02 ` [LTP] [PATCH 8/8] Hugetlb: Migrating libhugetlbfs misaligned_offset Tarun Sahu
-- strict thread matches above, loose matches on Subject: below --
2022-12-01 12:28 [LTP] [PATCH 0/8][PART 3] Hugetlb:Migrating the libhugetlbfs tests Tarun Sahu
2022-12-01 12:28 ` [LTP] [PATCH 1/8] Hugetlb: Migrating libhugetlbfs fork-cow Tarun Sahu
2022-12-05 12:28 ` Richard Palethorpe
2022-12-07 12:47 ` Tarun Sahu
2022-12-08 8:54 ` Richard Palethorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221201120248.139396-2-tsahu@linux.ibm.com \
--to=tsahu@linux.ibm.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=geetika@linux.ibm.com \
--cc=ltp@lists.linux.it \
--cc=sbhat@linux.ibm.com \
--cc=vaibhav@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.