From: Petr Vorel <pvorel@suse.cz>
To: Tarun Sahu <tsahu@linux.ibm.com>
Cc: sbhat@linux.ibm.com, aneesh.kumar@linux.ibm.com,
geetika@linux.ibm.com, vaibhav@linux.ibm.com,
rpalethorpe@suse.com, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2 4/8] Hugetlb: Migrating libhugetlbfs icache-hygiene
Date: Wed, 25 Jan 2023 02:11:09 +0100 [thread overview]
Message-ID: <Y9CBrSjw5pDu9Xa6@pevik> (raw)
In-Reply-To: <20221220063109.279007-5-tsahu@linux.ibm.com>
Hi Tarun, all,
> 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>
...
> +++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap15.c
...
> +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)
NOTE: do we consider riscv32 and mipsel32 as dead?
> + /* 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"
Because this, merged as 15625f6185 ("Hugetlb: Migrating libhugetlbfs
icache-hygiene") broke upcoming LTP release for these archs in Buildroot
toolchains. mipsel32 is quite old, but maybe some other distros still play
with riscv32.
IMHO instead of this there should have been using TST_TEST_TCONF() for
unsupported archs, I'll send patch tomorrow.
Kind regards,
Petr
> +#endif
> +}
...
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2023-01-25 1:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-20 6:31 [LTP] [PATCH v2 0/8][PART 3] Hugetlb:Migrating the libhugetlbfs tests Tarun Sahu
2022-12-20 6:31 ` [LTP] [PATCH v2 1/8] Hugetlb: Migrating libhugetlbfs fork-cow Tarun Sahu
2022-12-20 6:31 ` [LTP] [PATCH v2 2/8] Hugetlb: Migrating libhugetlbfs huge_at_4GB_normal_below Tarun Sahu
2022-12-20 6:31 ` [LTP] [PATCH v2 3/8] Hugetlb: Migrating libhugetlbfs huge_below_4GB_normal_above Tarun Sahu
2022-12-20 6:31 ` [LTP] [PATCH v2 4/8] Hugetlb: Migrating libhugetlbfs icache-hygiene Tarun Sahu
2023-01-25 1:11 ` Petr Vorel [this message]
2022-12-20 6:31 ` [LTP] [PATCH v2 5/8] Hugetlb: Migrating libhugetlbfs madvise_reserve Tarun Sahu
2022-12-20 6:31 ` [LTP] [PATCH v2 6/8] Hugetlb: Migrating libhugetlbfs map_high_truncate_2 Tarun Sahu
2022-12-20 6:31 ` [LTP] [PATCH v2 7/8] Hugetlb: Migrating libhugetlbfs misalign Tarun Sahu
2022-12-20 6:31 ` [LTP] [PATCH v2 8/8] Hugetlb: Migrating libhugetlbfs misaligned_offset Tarun Sahu
2022-12-20 12:48 ` [LTP] [PATCH v2 0/8][PART 3] Hugetlb:Migrating the libhugetlbfs tests Richard Palethorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9CBrSjw5pDu9Xa6@pevik \
--to=pvorel@suse.cz \
--cc=aneesh.kumar@linux.ibm.com \
--cc=geetika@linux.ibm.com \
--cc=ltp@lists.linux.it \
--cc=rpalethorpe@suse.com \
--cc=sbhat@linux.ibm.com \
--cc=tsahu@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