[PATCH] testsuite/smokey/alchemytests: Account for race condition inside QEMU

From: Jan Kiszka <[email protected]>

Let's cite claude on this which I used here to check its quality for
explaining such issues:

  Looking at the end of each task:

  - BGND (prio 20, line 28-32): signals 2<<18, loops back, exits loop,
    calls rt_event_wait at line 32.
  - FGND (prio 21, line 56-59): exits loop, calls
    rt_task_sleep(1000000ULL) (1 ms), then rt_event_delete.

  The intended ordering relies on two assumptions:

  1. After BGND signals at iteration 9, FGND preempts and runs its tail,
     then sleeps 1 ms.
  2. Within that 1 ms, BGND returns from the signal syscall, exits the
     loop, and re-enters the kernel via rt_event_wait — i.e., gets onto
     the wait queue.

  Both assumptions are usually true on real hardware but fragile in
  QEMU: virtualization adds large, jittery scheduling latency. Anything
  that delays BGND between line 28 (return from signal) and line 32
  (entry to wait) by more than ~1 ms — e.g., host scheduler preemption,
  timer-tick-driven simulated timekeeping, demand paging the
  libc/alchemy code — pushes the delete ahead of the wait, producing
  exactly EINVAL.

  Most likely explanations (in order)

  1. Scheduling race amplified by QEMU. The 1 ms guard in FGND is too
     tight under virtualized timing. BGND doesn't reach rt_event_wait
     before rt_event_delete runs, so find_alchemy_event fails and
     returns -EINVAL instead of the post-block -EIDRM. The error code
     itself is the smoking gun — EINVAL from the wait path can
     essentially only come from the pre-block lookup.
  ...

Claude was only given the Xenomai code in next and the extract of the
error log:

2026-04-27T17:06:37 alchemytests_buffer1 OK
2026-04-27T17:06:37    0"078.764| BUG in __traceobj_check_abort(): [BGND] wrong return status:
2026-04-27T17:06:37               event-1.c:33 => EINVAL (want EIDRM)
2026-04-27T17:06:37 test alchemytests_event1 failed: 256

Not bad. Mitigation was not vibe-coded to avoid arguing over copyright.

It's hard to ensure that BGND is actually blocked on the event before
deleting it, so do not bother raising the delay, just address the effect
and avoid a test failure.

See also #52, https://gitlab.com/Xenomai/xenomai-images/-/jobs/11416004714.

Signed-off-by: Jan Kiszka <[email protected]>
---

"Baked for 1m 53s" with opus-4.7.

If someone wants to try out different models or play with giving models 
more context, this could be a reference. Or the other issues we have 
open around #52. Still low-hanging fruits for AI - but maybe a chance to 
validate less frontier'ish options.

 testsuite/smokey/alchemytests/event-1.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/testsuite/smokey/alchemytests/event-1.c b/testsuite/smokey/alchemytests/event-1.c
index 9ce679c717..d691192ec9 100644
--- a/testsuite/smokey/alchemytests/event-1.c
+++ b/testsuite/smokey/alchemytests/event-1.c
@@ -11,6 +11,8 @@ static RT_TASK t_bgnd, t_fgnd;
 
 static RT_EVENT event;
 
+static bool on_vm;
+
 static void background_task(void *arg)
 {
 	unsigned int flags;
@@ -30,7 +32,7 @@ static void background_task(void *arg)
 	}
 
 	ret = rt_event_wait(&event, 0x55555, &flags, EV_ANY, TM_INFINITE);
-	traceobj_check(&trobj, ret, -EIDRM);
+	traceobj_assert(&trobj, ret == -EIDRM || (on_vm && ret == -EINVAL));
 
 	traceobj_exit(&trobj);
 }
@@ -67,6 +69,8 @@ int main(int argc, char *const argv[])
 	unsigned int flags;
 	int ret;
 
+	on_vm = argc > 1 && strcmp(argv[1], "--vm") == 0;
+
 	traceobj_init(&trobj, argv[0], 0);
 
 	ret = rt_event_create(&event, "EVENT", 0, EV_FIFO);
-- 
2.47.3