public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Tarun Sahu <tsahu@linux.ibm.com>
To: ltp@lists.linux.it
Cc: geetika@linux.ibm.com, sbhat@linux.ibm.com,
	aneesh.kumar@linux.ibm.com, vaibhav@linux.ibm.com
Subject: [LTP] [PATCH 4/8] Hugetlb: Migrating libhugetlbfs icache-hygiene
Date: Thu,  1 Dec 2022 17:32:44 +0530	[thread overview]
Message-ID: <20221201120248.139396-5-tsahu@linux.ibm.com> (raw)
In-Reply-To: <20221201120248.139396-1-tsahu@linux.ibm.com>

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

  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   ` [LTP] [PATCH 1/8] Hugetlb: Migrating libhugetlbfs fork-cow Tarun Sahu
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   ` Tarun Sahu [this message]
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 4/8] Hugetlb: Migrating libhugetlbfs icache-hygiene Tarun Sahu
2022-12-12 14:08   ` Richard Palethorpe
2022-12-13 17:27     ` Tarun Sahu
2022-12-19 21:01       ` Tarun Sahu

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-5-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox