Re: Dovetail 6.15: x86: Invalid wait context

[Philippe Gerum <rpm@xenomai.org>]

"Bezdeka, Florian" <florian.bezdeka@siemens.com> writes:

> On Thu, 2025-06-05 at 10:14 +0200, Florian Bezdeka wrote:
>> On Thu, 2025-06-05 at 10:00 +0200, Philippe Gerum wrote:
>> > Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>> > 
>> > > Hi Philippe,
>> > > 
>> > > the following is taken from our CI, testing Dovetail 6.15.
>> > > On x86 we have an invalid wait context reported:
>> > > 
>> > > [  151.574032] 
>> > > [  151.574039] =============================
>> > > [  151.574043] [ BUG: Invalid wait context ]
>> > > [  151.574046] 6.15.0 #1 Not tainted
>> > > [  151.574048] -----------------------------
>> > > [  151.574048] swapper/0/0 is trying to lock:
>> > > [  151.574050] ffffffff841174c0 (&state->readq){....}-{3:3}, at: __wake_up+0x21/0x60
>> > > [  151.574063] other info that might help us debug this:
>> > > [  151.574064] context-{2:2}
>> > > [  151.574065] no locks held by swapper/0/0.
>> > > [  151.574066] stack backtrace:
>> > > [  151.574073] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.15.0 #1 PREEMPT(full) 
>> > > [  151.574078] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
>> > > [  151.574079] IRQ stage: Linux
>> > > [  151.574083] Call Trace:
>> > > [  151.574086]  <IRQ>
>> > > [  151.574088]  dump_stack_lvl+0x79/0xe0
>> > > [  151.574095]  __lock_acquire+0x942/0xbf0
>> > > [  151.574104]  lock_acquire+0xe2/0x2f0
>> > > [  151.574107]  ? __wake_up+0x21/0x60
>> > > [  151.574111]  ? find_held_lock+0x2b/0x80
>> > > [  151.574115]  _raw_spin_lock_irqsave+0x49/0x60
>> > > [  151.574120]  ? __wake_up+0x21/0x60
>> > > [  151.574122]  __wake_up+0x21/0x60
>> > > [  151.574125]  xnpipe_wakeup_proc+0x152/0x590
>> > > [  151.574132]  handle_synthetic_irq+0xc2/0x250
>> > > [  151.574137]  arch_do_IRQ_pipelined+0xca/0x180
>> > > [  151.574141]  </IRQ>
>> > > [  151.574142]  <TASK>
>> > > [  151.574144]  sync_current_irq_stage+0xaa/0x110
>> > > [  151.574147]  inband_irq_enable+0x42/0x60
>> > > [  151.574151]  cpuidle_idle_call+0x17d/0x200
>> > > [  151.574155]  do_idle+0x89/0xd0
>> > > [  151.574158]  cpu_startup_entry+0x29/0x30
>> > > [  151.574160]  rest_init+0xf0/0x190
>> > > [  151.574164]  start_kernel+0x632/0x700
>> > > [  151.574179]  x86_64_start_reservations+0x18/0x30
>> > > [  151.574185]  x86_64_start_kernel+0x78/0x80
>> > > [  151.574188]  common_startup_64+0x13e/0x148
>> > > [  151.574198]  </TASK>
>> > > 
>> > > That seems to be triggered by the Xenomai 3 smokey testsuite.
>> > > 
>> > > Any ideas?
>> > 
>> > Does this happen when full preemption is disabled on x86?
>> 
>> Test-Log: https://lava.xenomai.org/scheduler/job/21679
>> Kernel-Config: https://source.denx.de/Xenomai/xenomai-images/-/blob/next/recipes-kernel/linux/files/amd64_defconfig?ref_type=heads
>> 
>
> Btw: Enabling CONFIG_DEBUG_ENTRY on 6.15 delivers:
>
> vmlinux.o: warning: objtool: do_int80_emulation+0x204: return with instrumentation enabled
> vmlinux.o: warning: objtool: irqentry_exit+0xdc: call to synchronize_pipeline() leaves .noinstr.text section
> vmlinux.o: warning: objtool: ct_idle_exit+0x1: call to inband_irq_save() leaves .noinstr.text section
> vmlinux.o: warning: objtool: cpuidle_enter_state+0x1a4: return with instrumentation enabled
> vmlinux.o: warning: objtool: default_idle+0x7: call to inband_irq_disable() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mwait_idle+0x44: call to inband_irq_disable() leaves .noinstr.text section
> vmlinux.o: warning: objtool: acpi_processor_ffh_cstate_enter+0x9a: call to inband_irq_disable() leaves .noinstr.text section
> vmlinux.o: warning: objtool: cpu_idle_poll.isra.0+0x60: call to inband_irq_enable() leaves .noinstr.text section
> vmlinux.o: warning: objtool: intel_idle_irq+0x54: call to inband_irq_disable() leaves .noinstr.text section
> vmlinux.o: warning: objtool: acpi_safe_halt+0x1a: call to inband_irq_disable() leaves .noinstr.text section
> vmlinux.o: warning: objtool: poll_idle+0x1d: call to inband_irq_enable() leaves .noinstr.text section
>
> Is that something we should look into?

Yes, we need to keep those calls within the instrumentation_begin/end
blocks, or annotate them. There are imbalanced calls to fix as well,
e.g.

diff --git a/arch/x86/entry/syscall_32.c b/arch/x86/entry/syscall_32.c
index 54749f4736633..cb1b4ad38568c 100644
--- a/arch/x86/entry/syscall_32.c
+++ b/arch/x86/entry/syscall_32.c
@@ -173,6 +173,7 @@ __visible noinstr void do_int80_emulation(struct pt_regs *regs)
 	if (dovetailing()) {
 		if (nr == EXIT_SYSCALL_OOB) {
 			hard_local_irq_disable();
+			instrumentation_end();
 			return;
 		}
 		if (nr == EXIT_SYSCALL_TAIL)

-- 
Philippe.