On Fri, 2022-12-23 at 13:02 +0100, Ilya Leoshkevich wrote:
> Add a test that locklessly changes and exercises page protection bits
> from various threads. This helps catch race conditions in the VMA
> handling.
>
> Signed-off-by: Ilya Leoshkevich <i...@linux.ibm.com>
> ---
> tests/tcg/multiarch/Makefile.target | 3 +
> tests/tcg/multiarch/munmap-pthread.c | 16 +--
> tests/tcg/multiarch/nop_func.h | 25 ++++
> tests/tcg/multiarch/vma-pthread.c | 185
> +++++++++++++++++++++++++++
> 4 files changed, 214 insertions(+), 15 deletions(-)
> create mode 100644 tests/tcg/multiarch/nop_func.h
> create mode 100644 tests/tcg/multiarch/vma-pthread.c
This was meant to be a reply to the bug report for [1], but apparently
I forgot to Cc: the mailing list. Copying the original message here:
---
Hi,
Wasmtime testsuite started failing randomly, complaining that
clock_gettime() returns -EFAULT. Bisect points to this commit.
I could not see anything obviously wrong here with the manual review,
and the failure was not reproducible when running individual testcases
or using strace. So I wrote a stress test (which I will post shortly),
which runs fine on the host, but reproduces the issue with qemu-user.
When run with -strace, it also triggers an assertion:
qemu-x86_64: ../accel/tcg/tb-maint.c:595:
tb_invalidate_phys_page_unwind: Assertion `pc != 0' failed.
qemu-x86_64: /home/iii/qemu/include/qemu/rcu.h:102:
rcu_read_unlock: Assertion `p_rcu_reader->depth != 0' failed.
I haven't tried analyzing what is causing all this yet, but at least
now the reproducer is small (~200LOC) and fails faster than 1s.
Best regards,
Ilya
---
[1] https://lists.gnu.org/archive/html/qemu-devel/2022-12/msg03615.html
