[dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Jan Kiszka]

[v2: rebased without changes, resent due to delivery issues of v1]

This is both an expression of personal laziness as well as an experiment
update about AI support for Xenomai core development - and it seems it
was fairly successful:

After noticing [1], I simply prompted in Opencode using Fable 5.1 to
review the ARM trap entry paths for inconsistencies:

"in arch/arm, analyse the annotation of trap entries with
dovetail_fault_entry and mark_trap_entry regarding completness and also
corresponding dovetail_fault_exit / mark_trap_exit"

For that, I just presented the wip/flo/v7.3-dovetail-rebase branch. And
the model came back with finding on [2] as well was these patches here.
Next, I asked for a review of arm64 and x86 as well, but there were no
findings.

Finally, I asked for the extension of smokey with some trap test cases
that demonstrate the ARM issues and test similar paths on arm64 and x86.
That turned out to be quite wasteful - I should have filtered out
irrelevant traps first, namely:

- ARM VFP exceptions - no hardware exit to stress them. But I'm leaving
  the related kernel patch in here because the code was already
  instrumented, just apparently incorrectly now.

- x86 Alignment Checks - can be enabled by userspace, but everything
  left and right in common libs will then explode. IOW, they have no use
  case in modern software. At the same time, some patching of libcobalt
  would be needed to handle SIGDEBUG for an #AC migration.

I will share the lengthy test case as well once I'm done with stripping
it down further (if possible). What the tests already demonstrated is
that unpatched kernels crash.

These patches here are almost completely generated. One of my few
contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
of having oob_trap_regs as a nesting detector came from the AI, though.

As usual, AI is still rather verbose in descriptions and comments. Some
of them I already shortened, but most is still left. We can cut down
further, but I would first of all like to have another review round.

While doing that, keep in mind that AI tends to ignore issues left and
right when being told to do a specific task. It may have simply missed
further preexisting issues or even created new ones now. Watch out!

That said, it is definitely impressing to see that a frontier model is
able to build up decent understanding of the Dovetail architecture
without further hand-holding. I would not blindly trust them yet, but
they seem to be ready now to act as debugging agent or at least
companion, even in complex scenarios. Giving some LLM access to a CI
pipeline may even result in automatic regression handling, probably
already today. Also, I want to explore what is helpful and reasonably
needed to support stable kernel maintenance.

Jan

PS: If someone is interested in the token costs: Due to my inefficient
model usage, the counter stopped at about 170 EUR. Most tokes went into
test case development and its debugging (#AC issues, e.g.). These
patches here likely costed about 40 EUR with Fable 5.1, checking the
other archs maybe another 30 EUR.

[1] https://lore.kernel.org/xenomai/8ecd3d1a-86d1-4f39-b175-b712c0be6eec@siemens.com/
[2] https://lore.kernel.org/xenomai/2e3b8eec-7911-4abe-8082-97296000e88d@siemens.com/

Jan Kiszka (4):
  dovetail: Track the owner of a trap notification by exception frame
  ARM: dovetail: Fix trap unwind condition in __und_svc
  ARM: dovetail: Notify the core about undefined instruction traps from
    user mode
  ARM: dovetail: Fix VFP exception trap notification

 arch/arm/include/asm/thread_info.h   |  1 -
 arch/arm/include/asm/traps.h         |  2 ++
 arch/arm/kernel/asm-offsets.c        |  2 --
 arch/arm/kernel/entry-armv.S         | 20 ++++----------------
 arch/arm/kernel/swp_emulate.c        | 22 ++++++++++++++++++----
 arch/arm/kernel/traps.c              | 27 +++++++++++++++++++++++++++
 arch/arm/probes/uprobes/core.c       | 10 ++++++++++
 arch/arm/vfp/vfpmodule.c             | 27 +++++++++++++++++++--------
 arch/arm64/include/asm/thread_info.h |  1 -
 arch/riscv/include/asm/thread_info.h |  1 -
 arch/x86/include/asm/thread_info.h   |  2 --
 include/linux/dovetail.h             | 12 ++++++++++--
 include/linux/sched.h                |  5 +++++
 kernel/dovetail.c                    | 10 ++++++++--
 14 files changed, 103 insertions(+), 39 deletions(-)

-- 
2.47.3

[dovetail][PATCH v2 1/4] dovetail: Track the owner of a trap notification by exception frame

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Trap notifications are guarded by _TLF_OOBTRAP: oob_trap_notify() only
calls into the companion core if the flag is clear, and sets it;
oob_trap_unwind() calls the exit handler and clears the flag whenever
it is set.

This does not cope with nested traps. A trap handler running on behalf
of an oob thread may trigger another trap before it reaches its own
exit annotation, e.g. a user access from an emulation handler faulting
in a not yet resident page on ARM:

  do_alignment()                      <- notify, _TLF_OOBTRAP set
    do_alignment_ldmstm()
      ldrt/strt to user address       <- translation fault (SVC mode)
        do_DataAbort()
          do_page_fault()
            dovetail_fault_entry()    <- notify suppressed, fine
            handle_mm_fault()
            dovetail_fault_exit()     <- unwind fires: wrong trap number,
                                         wrong frame, and the core may
                                         switch us back to oob
    ...emulation continues oob...
  dovetail_fault_exit()               <- no-op, flag already clear

Since _TLF_OOBTRAP is per-thread and the thread does not change across
nesting levels, the flag alone cannot tell which trap occurrence owns
the notification. The exception frame can: every nesting level pushes
its own pt_regs on the kernel stack, and the frame is already passed
to both the notify and unwind helpers.

Record the owning frame in the task struct when notifying, and only
unwind when the frame passed to oob_trap_unwind() matches. Inner trap
exits become no-ops, the outer exit unwinds with the trap number and
frame the core was notified with. oob_trap_regs can in fact encode the
semantic of the _TLF_OOBTRAP flag, thus drop it.

A forking parent can never be inside a trap handler, so neither the
flag nor the owner frame can legitimately be set when a new task
inherits its state. Add a debug assertion for this in
inband_task_init(), which turns an unbalanced trap entry into a
loud warning on the next fork instead of silently propagating the
stuck state to the children.

Assisted-by: opencode:Fable-5.1
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 arch/arm/include/asm/thread_info.h   |  1 -
 arch/arm64/include/asm/thread_info.h |  1 -
 arch/riscv/include/asm/thread_info.h |  1 -
 arch/x86/include/asm/thread_info.h   |  2 --
 include/linux/dovetail.h             | 12 ++++++++++--
 include/linux/sched.h                |  5 +++++
 kernel/dovetail.c                    | 10 ++++++++--
 7 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index 23cae59037c1e..12ab7e49b7b76 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -196,7 +196,6 @@ extern int vfp_restore_user_hwstate(struct user_vfp *,
 #define _TLF_OOB		0x0001
 #define _TLF_DOVETAIL		0x0002
 #define _TLF_OFFSTAGE		0x0004
-#define _TLF_OOBTRAP		0x0008
 
 #endif /* __KERNEL__ */
 #endif /* __ASM_ARM_THREAD_INFO_H */
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index 48563d782a99a..934b080246146 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -144,7 +144,6 @@ void arch_setup_new_exec(void);
 #define _TLF_OOB			0x0001
 #define _TLF_DOVETAIL			0x0002
 #define _TLF_OFFSTAGE			0x0004
-#define _TLF_OOBTRAP			0x0008
 #define _TLF_KERNEL_FPU_PREEMPTED	0x0010	/* Dovetail: kernel mode FPSIMD section preempted by OOB */
 
 #endif /* __ASM_THREAD_INFO_H */
diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h
index 820a596d9bf65..11164e12317fa 100644
--- a/arch/riscv/include/asm/thread_info.h
+++ b/arch/riscv/include/asm/thread_info.h
@@ -140,6 +140,5 @@ int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src);
 #define _TLF_OOB		0x0001
 #define _TLF_DOVETAIL		0x0002
 #define _TLF_OFFSTAGE		0x0004
-#define _TLF_OOBTRAP		0x0008
 
 #endif /* _ASM_RISCV_THREAD_INFO_H */
diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index 6da425bc87712..0c9cdf60e3f12 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -218,13 +218,11 @@ static inline int arch_within_stack_frames(const void * const stack,
 #define TS_OOB			0x0010	/* Thread is running out-of-band */
 #define TS_DOVETAIL		0x0020  /* Dovetail notifier enabled */
 #define TS_OFFSTAGE		0x0040	/* Thread is in-flight to OOB context */
-#define TS_OOBTRAP		0x0080	/* Handling a trap from OOB context */
 #define TS_KERNEL_FPU_PREEMPTED	0x0100	/* Dovetail: kernel mode FPU section preempted by OOB */
 
 #define _TLF_OOB			TS_OOB
 #define _TLF_DOVETAIL			TS_DOVETAIL
 #define _TLF_OFFSTAGE			TS_OFFSTAGE
-#define _TLF_OOBTRAP			TS_OOBTRAP
 #define _TLF_KERNEL_FPU_PREEMPTED	TS_KERNEL_FPU_PREEMPTED
 
 #ifndef __ASSEMBLER__
diff --git a/include/linux/dovetail.h b/include/linux/dovetail.h
index 1140c5b7c99f3..645d1eec32aa6 100644
--- a/include/linux/dovetail.h
+++ b/include/linux/dovetail.h
@@ -62,10 +62,18 @@ int pipeline_syscall(unsigned int nr, struct pt_regs *regs);
 void __oob_trap_notify(unsigned int exception,
 		       struct pt_regs *regs);
 
+/*
+ * Trap notifications do not nest: a trap handler running on behalf
+ * of an oob thread may itself trigger a fault (e.g. a user access
+ * from an emulation handler), landing into another annotated trap
+ * handler. Only the outermost trap occurrence notifies the companion
+ * core, which is told about the exit when that same occurrence
+ * unwinds.
+ */
 static __always_inline void oob_trap_notify(unsigned int exception,
 					struct pt_regs *regs)
 {
-	if (running_oob() && !test_thread_local_flags(_TLF_OOBTRAP))
+	if (running_oob() && !current->oob_trap_regs)
 		__oob_trap_notify(exception, regs);
 }
 
@@ -75,7 +83,7 @@ void __oob_trap_unwind(unsigned int exception,
 static __always_inline void oob_trap_unwind(unsigned int exception,
 					struct pt_regs *regs)
 {
-	if (test_thread_local_flags(_TLF_OOBTRAP))
+	if (current->oob_trap_regs == regs)
 		__oob_trap_unwind(exception, regs);
 }
 
diff --git a/include/linux/sched.h b/include/linux/sched.h
index c4291b7f7b6ea..3012926e8e355 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -74,6 +74,7 @@ struct perf_event_context;
 struct perf_ctx_data;
 struct pid_namespace;
 struct pipe_inode_info;
+struct pt_regs;
 struct rcu_node;
 struct reclaim_state;
 struct root_domain;
@@ -1302,6 +1303,10 @@ struct task_struct {
 #ifdef CONFIG_IRQ_PIPELINE
 	unsigned long			stall_bits;
 #endif
+#ifdef CONFIG_DOVETAIL
+	/* Exception frame owning the pending oob trap notification. */
+	struct pt_regs			*oob_trap_regs;
+#endif
 
 #ifdef CONFIG_LOCKDEP
 # define MAX_LOCK_DEPTH			48UL
diff --git a/kernel/dovetail.c b/kernel/dovetail.c
index 16ac66e4529f5..f196a9815dabd 100644
--- a/kernel/dovetail.c
+++ b/kernel/dovetail.c
@@ -22,6 +22,12 @@ void inband_task_init(struct task_struct *p)
 {
 	struct thread_info *ti = task_thread_info(p);
 
+	/*
+	 * A forking parent cannot be inside a trap handler. If oob_trap_regs
+	 * is non-NULL, some trap entry was not balanced by a matching exit.
+	 */
+	WARN_ON_ONCE(dovetail_debug() && p->oob_trap_regs);
+
 	clear_ti_local_flags(ti, _TLF_DOVETAIL|_TLF_OOB|_TLF_OFFSTAGE);
 	arch_inband_task_init(p);
 }
@@ -284,7 +290,7 @@ noinstr void __oob_trap_notify(unsigned int exception,
 	 * to the in-band stage, may return with hard irqs on.
 	 */
 	if (dovetail_enabled) {
-		set_thread_local_flags(_TLF_OOBTRAP);
+		current->oob_trap_regs = regs;
 		flags = hard_local_irq_save();
 		instrumentation_begin();
 		handle_oob_trap_entry(exception, regs);
@@ -306,7 +312,7 @@ noinstr void __oob_trap_unwind(unsigned int exception, struct pt_regs *regs)
 	 * stage. Must return with hard irqs off.
 	 */
 	hard_local_irq_disable();
-	clear_thread_local_flags(_TLF_OOBTRAP);
+	current->oob_trap_regs = NULL;
 	instrumentation_begin();
 	handle_oob_trap_exit(exception, regs);
 	instrumentation_end();
-- 
2.47.3

[dovetail][PATCH v2 2/4] ARM: dovetail: Fix trap unwind condition in __und_svc

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

The kernel mode undefined instruction entry notifies the companion
core from assembly, testing the current stage both before the notify
and before the unwind call. The second test is wrong: if the core
demoted the thread to in-band upon notification - the common case -
the thread is no longer running oob when __und_svc_finish is reached,
so the unwind is skipped altogether. As a result,

- handle_oob_trap_exit() is never called for that trap,

- oob_trap_regs stays set, suppressing every later trap notification
  for this thread until some unrelated trap exit eventually clears it
  with a stale unwind.

The C helpers get this right, keying the unwind on the owning exception
frame, not on the stage, also acting as nesting guard.

Replace the open-coded tests with calls to small asmlinkage wrappers
around oob_trap_notify()/oob_trap_unwind(), so that the assembly entry
follows the exact same rules as the C trap handlers. Overhead is
negligible in the exception path. The wrappers are blacklisted from
kprobes like do_undefinstr(), since a probe there would recurse through
__und_svc.

The TI_PIPELINE_STATE/TI_OOB_MASK offsets and the asm/dovetail.h
inclusion in entry-armv.S have no users left, drop them.

Assisted-by: opencode:Fable-5.1
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 arch/arm/include/asm/traps.h  |  2 ++
 arch/arm/kernel/asm-offsets.c |  2 --
 arch/arm/kernel/entry-armv.S  | 20 ++++----------------
 arch/arm/kernel/traps.c       | 15 +++++++++++++++
 4 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/arch/arm/include/asm/traps.h b/arch/arm/include/asm/traps.h
index 2621b9fb9b19b..8f7d526c36ecc 100644
--- a/arch/arm/include/asm/traps.h
+++ b/arch/arm/include/asm/traps.h
@@ -44,5 +44,7 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs);
 asmlinkage void baddataabort(int code, unsigned long instr, struct pt_regs *regs);
 asmlinkage void __div0(void);
 asmlinkage void handle_bad_stack(struct pt_regs *regs);
+asmlinkage void und_svc_trap_notify(struct pt_regs *regs);
+asmlinkage void und_svc_trap_unwind(struct pt_regs *regs);
 
 #endif
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index a5e5a666930ae..6135e9352335b 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -55,8 +55,6 @@ int main(void)
   DEFINE(TI_ABI_SYSCALL,	offsetof(struct thread_info, abi_syscall));
   DEFINE(TI_TP_VALUE,		offsetof(struct thread_info, tp_value));
   DEFINE(TI_FPSTATE,		offsetof(struct thread_info, fpstate));
-  DEFINE(TI_PIPELINE_STATE,	offsetof(struct thread_info, irq_pipeline_state));
-  DEFINE(TI_OOB_MASK,		STAGE_MASK);
 #ifdef CONFIG_VFP
   DEFINE(TI_VFPSTATE,		offsetof(struct thread_info, vfpstate));
 #ifdef CONFIG_SMP
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index a314c3152072b..1f44c9fad0186 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -30,7 +30,6 @@
 
 #include "entry-header.S"
 #include <asm/probes.h>
-#include <asm/dovetail.h>
 
 #ifdef CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION
 #define RELOC_TEXT_NONE .reloc  .text, R_ARM_NONE, .
@@ -298,14 +297,8 @@ __und_svc:
 	svc_entry
 #endif
 #ifdef CONFIG_DOVETAIL
-	get_thread_info tsk
-	ldr	r0, [tsk, #TI_PIPELINE_STATE]	@ get pipeline state
-	tst	r0, #TI_OOB_MASK		@ oob stage?
-	beq	1f
-	mov	r0, #ARM_TRAP_UNDEFINSTR
-	mov	r1, sp				@ r1 = &regs
-	bl	__oob_trap_notify
-1:
+	mov	r0, sp				@ struct pt_regs *regs
+	bl	und_svc_trap_notify
 #endif
 
 	mov	r1, #4				@ PC correction to apply
@@ -317,13 +310,8 @@ __und_svc:
 __und_svc_finish:
 	get_thread_info tsk
 #ifdef CONFIG_DOVETAIL
-	ldr	r0, [tsk, #TI_PIPELINE_STATE]	@ get pipeline state
-	tst	r0, #TI_OOB_MASK		@ oob stage?
-	beq	1f
-	mov	r0, #ARM_TRAP_UNDEFINSTR
-	mov	r1, sp				@ r1 = &regs
-	bl	__oob_trap_unwind
-1:
+	mov	r0, sp				@ struct pt_regs *regs
+	bl	und_svc_trap_unwind
 #endif
 	ldr	r5, [sp, #S_PSR]		@ Get SVC cpsr
 	svc_exit r5				@ return from exception
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 60c4725fa8530..8ca5ba26d2598 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -27,6 +27,7 @@
 #include <linux/sched/task_stack.h>
 #include <linux/irq.h>
 #include <linux/vmalloc.h>
+#include <linux/dovetail.h>
 
 #include <linux/atomic.h>
 #include <asm/cacheflush.h>
@@ -495,6 +496,20 @@ asmlinkage void do_undefinstr(struct pt_regs *regs)
 }
 NOKPROBE_SYMBOL(do_undefinstr)
 
+#ifdef CONFIG_DOVETAIL
+asmlinkage void und_svc_trap_notify(struct pt_regs *regs)
+{
+	oob_trap_notify(ARM_TRAP_UNDEFINSTR, regs);
+}
+NOKPROBE_SYMBOL(und_svc_trap_notify)
+
+asmlinkage void und_svc_trap_unwind(struct pt_regs *regs)
+{
+	oob_trap_unwind(ARM_TRAP_UNDEFINSTR, regs);
+}
+NOKPROBE_SYMBOL(und_svc_trap_unwind)
+#endif /* CONFIG_DOVETAIL */
+
 /*
  * Handle FIQ similarly to NMI on x86 systems.
  *
-- 
2.47.3

[dovetail][PATCH v2 3/4] ARM: dovetail: Notify the core about undefined instruction traps from user mode

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Unlike the kernel mode entry (__und_svc), the user mode undefined
instruction path does not inform the companion core at all. This is
intended for the undef hooks which must stay oob-capable, like the
lazy VFP state restore in vfp_support_entry(), but leaves the in-band
fallbacks of that path unannotated, so an oob thread may run them
from the oob stage:

- do_undefinstr() raising SIGILL when no hook claimed the instruction
  or the instruction could not be read from user memory,

- swp_handler() emulating SWP{B}, which accesses user memory (and may
  fault in pages), takes the mmap lock and raises SIGSEGV on errors,

- uprobe_trap_handler(), which depends on the in-band return to user
  path for running the probe handlers, a path an oob thread skips.

Annotate them. do_undefinstr() uses the conditional form, since the
companion core may want to handle an undefined instruction of an oob
thread entirely from the oob stage, in which case it does not demote
the thread and we must not inject the in-band signal (this is the
behavior arm64 implements in do_el0_undef()). Kernel mode faults are
already covered by the notification issued from __und_svc, don't
notify twice.

swp_handler() and uprobe_trap_handler() are restricted to user mode
by their hook descriptors and always need the in-band stage, so they
use the strict form like break_trap() does.

Assisted-by: opencode:Fable-5.1
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 arch/arm/kernel/swp_emulate.c  | 22 ++++++++++++++++++----
 arch/arm/kernel/traps.c        | 12 ++++++++++++
 arch/arm/probes/uprobes/core.c | 10 ++++++++++
 3 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/swp_emulate.c b/arch/arm/kernel/swp_emulate.c
index fdce83c95acb0..39b45c598f7f0 100644
--- a/arch/arm/kernel/swp_emulate.c
+++ b/arch/arm/kernel/swp_emulate.c
@@ -23,6 +23,7 @@
 #include <linux/sched/mm.h>
 #include <linux/syscalls.h>
 #include <linux/perf_event.h>
+#include <linux/dovetail.h>
 
 #include <asm/opcodes.h>
 #include <asm/system_info.h>
@@ -161,6 +162,14 @@ static int swp_handler(struct pt_regs *regs, unsigned int instr)
 {
 	unsigned int address, destreg, data, type;
 	unsigned int res = 0;
+	int ret = 0;
+
+	/*
+	 * Dovetail: emulating the access may fault on user memory,
+	 * and failures are reported by signal. We need to run
+	 * in-band for this, have the companion core demote us.
+	 */
+	mark_trap_entry(ARM_TRAP_UNDEFINSTR, regs);
 
 	perf_sw_event(PERF_COUNT_SW_EMULATION_FAULTS, 1, regs, regs->ARM_pc);
 
@@ -171,12 +180,14 @@ static int swp_handler(struct pt_regs *regs, unsigned int instr)
 	case ARM_OPCODE_CONDTEST_FAIL:
 		/* Condition failed - return to next instruction */
 		regs->ARM_pc += 4;
-		return 0;
+		goto out;
 	case ARM_OPCODE_CONDTEST_UNCOND:
 		/* If unconditional encoding - not a SWP, undef */
-		return -EFAULT;
+		ret = -EFAULT;
+		goto out;
 	default:
-		return -EINVAL;
+		ret = -EINVAL;
+		goto out;
 	}
 
 	if (current->pid != previous_pid) {
@@ -220,7 +231,10 @@ static int swp_handler(struct pt_regs *regs, unsigned int instr)
 		set_segfault(regs, address);
 	}
 
-	return 0;
+out:
+	mark_trap_exit(ARM_TRAP_UNDEFINSTR, regs);
+
+	return ret;
 }
 
 /*
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 8ca5ba26d2598..059a1dc900431 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -483,6 +483,16 @@ asmlinkage void do_undefinstr(struct pt_regs *regs)
 		return;
 
 die_sig:
+	/*
+	 * Dovetail: the companion core may handle an undefined
+	 * instruction raised by an oob thread entirely from the oob
+	 * stage, in which case it does not demote us to in-band and
+	 * we must not apply the in-band fixup. The kernel mode case
+	 * was notified from __und_svc already.
+	 */
+	if (user_mode(regs) &&
+	    !mark_cond_trap_entry(ARM_TRAP_UNDEFINSTR, regs))
+		return;
 #ifdef CONFIG_DEBUG_USER
 	if (user_debug & UDBG_UNDEFINED) {
 		pr_info("%s (%d): undefined instruction: pc=%px\n",
@@ -493,6 +503,8 @@ asmlinkage void do_undefinstr(struct pt_regs *regs)
 #endif
 	arm_notify_die("Oops - undefined instruction", regs,
 		       SIGILL, ILL_ILLOPC, pc, 0, 6);
+	if (user_mode(regs))
+		mark_trap_exit(ARM_TRAP_UNDEFINSTR, regs);
 }
 NOKPROBE_SYMBOL(do_undefinstr)
 
diff --git a/arch/arm/probes/uprobes/core.c b/arch/arm/probes/uprobes/core.c
index 0e1c6b9e7e54a..06b3b5e37e73d 100644
--- a/arch/arm/probes/uprobes/core.c
+++ b/arch/arm/probes/uprobes/core.c
@@ -10,6 +10,7 @@
 #include <linux/sched.h>
 #include <linux/uprobes.h>
 #include <linux/notifier.h>
+#include <linux/dovetail.h>
 
 #include <asm/opcodes.h>
 #include <asm/traps.h>
@@ -185,6 +186,13 @@ static int uprobe_trap_handler(struct pt_regs *regs, unsigned int instr)
 {
 	unsigned long flags;
 
+	/*
+	 * Dovetail: uprobe handling runs from the in-band return to
+	 * user path, which an oob thread would skip. Have the
+	 * companion core demote us first.
+	 */
+	mark_trap_entry(ARM_TRAP_BREAK, regs);
+
 	local_irq_save(flags);
 	instr &= 0x0fffffff;
 	if (instr == (UPROBE_SWBP_ARM_INSN & 0x0fffffff))
@@ -193,6 +201,8 @@ static int uprobe_trap_handler(struct pt_regs *regs, unsigned int instr)
 		uprobe_post_sstep_notifier(regs);
 	local_irq_restore(flags);
 
+	mark_trap_exit(ARM_TRAP_BREAK, regs);
+
 	return 0;
 }
 
-- 
2.47.3

[dovetail][PATCH v2 4/4] ARM: dovetail: Fix VFP exception trap notification

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

The trap annotation of the VFP bounce path predates upstream
commit c0b5195bad63 ("ARM: 9426/1: vfp: Move sending signals outside of vfp_state_hold()ed section.")
which turned vfp_raise_exceptions() into returning the si_code,
deferring vfp_raise_sigfpe() to the exit of VFP_bounce() after
vfp_state_release(). The Dovetail hunk was kept in place verbatim,
which is now wrong in three ways:

- for VFP_EXCEPTION_ERROR, SIGFPE is sent twice: once from the
  annotated block in vfp_raise_exceptions(), once more from the exit
  path of VFP_bounce() via the returned si_code,

- the deferred signals for regular FP exceptions enabled in FPSCR
  (divide by zero, overflow, ...) are not annotated at all, so an oob
  thread sends them from the oob stage,

- the annotated block runs within the vfp_state_hold() section, which
  under Dovetail is a hard_preempt_disable() section. If the core
  demotes the thread to in-band from there, hard_preempt_enable()
  pairs an oob-stage hard_preempt_disable() which did not touch the
  preemption count with an in-band preempt_enable_no_resched(),
  unbalancing it. Besides, that was the very reason for the upstream
  change on PREEMPT_RT.

Move the notification to the exit path of VFP_bounce(), after the
VFP state was released: if any signal is to be raised, have the
companion core demote the thread, or skip the signal if the core
decided to handle the trap from the oob stage. This mirrors what
arm64 does for ARM64_TRAP_FPE in do_fpsimd_exc().

vfp_raise_exceptions() does not need the register frame anymore,
restore its upstream signature.

Assisted-by: opencode:Fable-5.1
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 arch/arm/vfp/vfpmodule.c | 27 +++++++++++++++++++--------
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 4bbe92c619f2d..5589eb76379b5 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -283,7 +283,7 @@ static void vfp_panic(char *reason, u32 inst)
 /*
  * Process bitmask of exception conditions.
  */
-static int vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_regs *regs)
+static int vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr)
 {
 	int si_code = 0;
 
@@ -291,10 +291,6 @@ static int vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_r
 
 	if (exceptions == VFP_EXCEPTION_ERROR) {
 		vfp_panic("unhandled bounce", inst);
-		if (mark_cond_trap_entry(ARM_TRAP_VFP, regs)) {
-			vfp_raise_sigfpe(FPE_FLTINV, regs);
-			mark_trap_exit(ARM_TRAP_VFP, regs);
-		}
 		return FPE_FLTINV;
 	}
 
@@ -437,7 +433,7 @@ static void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs, unsigned lo
 		 * unallocated VFP instruction but with FPSCR.IXE set and not
 		 * on VFP subarch 1.
 		 */
-		si_code = vfp_raise_exceptions(VFP_EXCEPTION_ERROR, trigger, fpscr, regs);
+		si_code = vfp_raise_exceptions(VFP_EXCEPTION_ERROR, trigger, fpscr);
 		goto exit;
 	}
 
@@ -462,7 +458,7 @@ static void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs, unsigned lo
 	 */
 	exceptions = vfp_emulate_instruction(trigger, fpscr, regs);
 	if (exceptions)
-		si_code2 = vfp_raise_exceptions(exceptions, trigger, orig_fpscr, regs);
+		si_code2 = vfp_raise_exceptions(exceptions, trigger, orig_fpscr);
 
 	/*
 	 * If there isn't a second FP instruction, exit now. Note that
@@ -476,13 +472,28 @@ static void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs, unsigned lo
 emulate:
 	exceptions = vfp_emulate_instruction(trigger, orig_fpscr, regs);
 	if (exceptions)
-		si_code = vfp_raise_exceptions(exceptions, trigger, orig_fpscr, regs);
+		si_code = vfp_raise_exceptions(exceptions, trigger, orig_fpscr);
 exit:
 	vfp_state_release(flags);
+
+	if (!si_code && !si_code2)
+		return;
+
+	/*
+	 * Dovetail: the companion core may handle the FP exception of
+	 * an oob thread entirely from the oob stage, in which case it
+	 * does not demote us to in-band and we must not raise the
+	 * signal. Otherwise, we run in-band from this point.
+	 */
+	if (!mark_cond_trap_entry(ARM_TRAP_VFP, regs))
+		return;
+
 	if (si_code2)
 		vfp_raise_sigfpe(si_code2, regs);
 	if (si_code)
 		vfp_raise_sigfpe(si_code, regs);
+
+	mark_trap_exit(ARM_TRAP_VFP, regs);
 }
 
 static void vfp_enable(void *unused)
-- 
2.47.3

Re: [dovetail][PATCH v2 1/4] dovetail: Track the owner of a trap notification by exception frame

[Florian Bezdeka]

On Wed, 2026-11-11 at 13:10 +0100, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Trap notifications are guarded by _TLF_OOBTRAP: oob_trap_notify() only
> calls into the companion core if the flag is clear, and sets it;
> oob_trap_unwind() calls the exit handler and clears the flag whenever
> it is set.
> 
> This does not cope with nested traps. A trap handler running on behalf
> of an oob thread may trigger another trap before it reaches its own
> exit annotation, e.g. a user access from an emulation handler faulting
> in a not yet resident page on ARM:
> 
>   do_alignment()                      <- notify, _TLF_OOBTRAP set
>     do_alignment_ldmstm()
>       ldrt/strt to user address       <- translation fault (SVC mode)
>         do_DataAbort()
>           do_page_fault()
>             dovetail_fault_entry()    <- notify suppressed, fine
>             handle_mm_fault()
>             dovetail_fault_exit()     <- unwind fires: wrong trap number,
>                                          wrong frame, and the core may
>                                          switch us back to oob
>     ...emulation continues oob...
>   dovetail_fault_exit()               <- no-op, flag already clear
> 
> Since _TLF_OOBTRAP is per-thread and the thread does not change across
> nesting levels, the flag alone cannot tell which trap occurrence owns
> the notification. The exception frame can: every nesting level pushes
> its own pt_regs on the kernel stack, and the frame is already passed
> to both the notify and unwind helpers.
> 
> Record the owning frame in the task struct when notifying, and only
> unwind when the frame passed to oob_trap_unwind() matches. Inner trap
> exits become no-ops, the outer exit unwinds with the trap number and
> frame the core was notified with. oob_trap_regs can in fact encode the
> semantic of the _TLF_OOBTRAP flag, thus drop it.

struct task_struct is also per-thread. The migrating from thread_info to
task_struct for bookkeeping makes the implementation arch independent.
Which is nice, but not mentioned here.

The implementation looks sane.

> 
> A forking parent can never be inside a trap handler, so neither the
> flag nor the owner frame can legitimately be set when a new task
> inherits its state. Add a debug assertion for this in
> inband_task_init(), which turns an unbalanced trap entry into a
> loud warning on the next fork instead of silently propagating the
> stuck state to the children.
> 
> Assisted-by: opencode:Fable-5.1
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  arch/arm/include/asm/thread_info.h   |  1 -
>  arch/arm64/include/asm/thread_info.h |  1 -
>  arch/riscv/include/asm/thread_info.h |  1 -
>  arch/x86/include/asm/thread_info.h   |  2 --
>  include/linux/dovetail.h             | 12 ++++++++++--
>  include/linux/sched.h                |  5 +++++
>  kernel/dovetail.c                    | 10 ++++++++--
>  7 files changed, 23 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
> index 23cae59037c1e..12ab7e49b7b76 100644
> --- a/arch/arm/include/asm/thread_info.h
> +++ b/arch/arm/include/asm/thread_info.h
> @@ -196,7 +196,6 @@ extern int vfp_restore_user_hwstate(struct user_vfp *,
>  #define _TLF_OOB		0x0001
>  #define _TLF_DOVETAIL		0x0002
>  #define _TLF_OFFSTAGE		0x0004
> -#define _TLF_OOBTRAP		0x0008
>  
>  #endif /* __KERNEL__ */
>  #endif /* __ASM_ARM_THREAD_INFO_H */
> diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
> index 48563d782a99a..934b080246146 100644
> --- a/arch/arm64/include/asm/thread_info.h
> +++ b/arch/arm64/include/asm/thread_info.h
> @@ -144,7 +144,6 @@ void arch_setup_new_exec(void);
>  #define _TLF_OOB			0x0001
>  #define _TLF_DOVETAIL			0x0002
>  #define _TLF_OFFSTAGE			0x0004
> -#define _TLF_OOBTRAP			0x0008
>  #define _TLF_KERNEL_FPU_PREEMPTED	0x0010	/* Dovetail: kernel mode FPSIMD section preempted by OOB */
>  
>  #endif /* __ASM_THREAD_INFO_H */
> diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h
> index 820a596d9bf65..11164e12317fa 100644
> --- a/arch/riscv/include/asm/thread_info.h
> +++ b/arch/riscv/include/asm/thread_info.h
> @@ -140,6 +140,5 @@ int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src);
>  #define _TLF_OOB		0x0001
>  #define _TLF_DOVETAIL		0x0002
>  #define _TLF_OFFSTAGE		0x0004
> -#define _TLF_OOBTRAP		0x0008
>  
>  #endif /* _ASM_RISCV_THREAD_INFO_H */
> diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
> index 6da425bc87712..0c9cdf60e3f12 100644
> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -218,13 +218,11 @@ static inline int arch_within_stack_frames(const void * const stack,
>  #define TS_OOB			0x0010	/* Thread is running out-of-band */
>  #define TS_DOVETAIL		0x0020  /* Dovetail notifier enabled */
>  #define TS_OFFSTAGE		0x0040	/* Thread is in-flight to OOB context */
> -#define TS_OOBTRAP		0x0080	/* Handling a trap from OOB context */
>  #define TS_KERNEL_FPU_PREEMPTED	0x0100	/* Dovetail: kernel mode FPU section preempted by OOB */
>  
>  #define _TLF_OOB			TS_OOB
>  #define _TLF_DOVETAIL			TS_DOVETAIL
>  #define _TLF_OFFSTAGE			TS_OFFSTAGE
> -#define _TLF_OOBTRAP			TS_OOBTRAP
>  #define _TLF_KERNEL_FPU_PREEMPTED	TS_KERNEL_FPU_PREEMPTED
>  
>  #ifndef __ASSEMBLER__
> diff --git a/include/linux/dovetail.h b/include/linux/dovetail.h
> index 1140c5b7c99f3..645d1eec32aa6 100644
> --- a/include/linux/dovetail.h
> +++ b/include/linux/dovetail.h
> @@ -62,10 +62,18 @@ int pipeline_syscall(unsigned int nr, struct pt_regs *regs);
>  void __oob_trap_notify(unsigned int exception,
>  		       struct pt_regs *regs);
>  
> +/*
> + * Trap notifications do not nest: a trap handler running on behalf
> + * of an oob thread may itself trigger a fault (e.g. a user access
> + * from an emulation handler), landing into another annotated trap
> + * handler. Only the outermost trap occurrence notifies the companion
> + * core, which is told about the exit when that same occurrence
> + * unwinds.
> + */
>  static __always_inline void oob_trap_notify(unsigned int exception,
>  					struct pt_regs *regs)
>  {
> -	if (running_oob() && !test_thread_local_flags(_TLF_OOBTRAP))
> +	if (running_oob() && !current->oob_trap_regs)
>  		__oob_trap_notify(exception, regs);
>  }
>  
> @@ -75,7 +83,7 @@ void __oob_trap_unwind(unsigned int exception,
>  static __always_inline void oob_trap_unwind(unsigned int exception,
>  					struct pt_regs *regs)
>  {
> -	if (test_thread_local_flags(_TLF_OOBTRAP))
> +	if (current->oob_trap_regs == regs)
>  		__oob_trap_unwind(exception, regs);
>  }
>  
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index c4291b7f7b6ea..3012926e8e355 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -74,6 +74,7 @@ struct perf_event_context;
>  struct perf_ctx_data;
>  struct pid_namespace;
>  struct pipe_inode_info;
> +struct pt_regs;
>  struct rcu_node;
>  struct reclaim_state;
>  struct root_domain;
> @@ -1302,6 +1303,10 @@ struct task_struct {
>  #ifdef CONFIG_IRQ_PIPELINE
>  	unsigned long			stall_bits;
>  #endif
> +#ifdef CONFIG_DOVETAIL
> +	/* Exception frame owning the pending oob trap notification. */
> +	struct pt_regs			*oob_trap_regs;
> +#endif
>  
>  #ifdef CONFIG_LOCKDEP
>  # define MAX_LOCK_DEPTH			48UL
> diff --git a/kernel/dovetail.c b/kernel/dovetail.c
> index 16ac66e4529f5..f196a9815dabd 100644
> --- a/kernel/dovetail.c
> +++ b/kernel/dovetail.c
> @@ -22,6 +22,12 @@ void inband_task_init(struct task_struct *p)
>  {
>  	struct thread_info *ti = task_thread_info(p);
>  
> +	/*
> +	 * A forking parent cannot be inside a trap handler. If oob_trap_regs
> +	 * is non-NULL, some trap entry was not balanced by a matching exit.
> +	 */
> +	WARN_ON_ONCE(dovetail_debug() && p->oob_trap_regs);
> +
>  	clear_ti_local_flags(ti, _TLF_DOVETAIL|_TLF_OOB|_TLF_OFFSTAGE);
>  	arch_inband_task_init(p);
>  }
> @@ -284,7 +290,7 @@ noinstr void __oob_trap_notify(unsigned int exception,
>  	 * to the in-band stage, may return with hard irqs on.
>  	 */
>  	if (dovetail_enabled) {
> -		set_thread_local_flags(_TLF_OOBTRAP);
> +		current->oob_trap_regs = regs;
>  		flags = hard_local_irq_save();
>  		instrumentation_begin();
>  		handle_oob_trap_entry(exception, regs);
> @@ -306,7 +312,7 @@ noinstr void __oob_trap_unwind(unsigned int exception, struct pt_regs *regs)
>  	 * stage. Must return with hard irqs off.
>  	 */
>  	hard_local_irq_disable();
> -	clear_thread_local_flags(_TLF_OOBTRAP);
> +	current->oob_trap_regs = NULL;
>  	instrumentation_begin();
>  	handle_oob_trap_exit(exception, regs);
>  	instrumentation_end();
> -- 
> 2.47.3

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Florian Bezdeka]

On Wed, 2026-11-11 at 13:10 +0100, Jan Kiszka wrote:
> [v2: rebased without changes, resent due to delivery issues of v1]
> 

While reviewing the risc-v implementation - and comparing it to all the
other archs - arm included - I already noticed some problematic cases in
arm.

I was able to address/fix some of them already, a couple of TODOs were
still on my list.

2/4 and 3/4 where on that list - with patches already prepared but
untested, so not published yet - 4/4 was not on the radar yet, 1/4 came
up while looking at the other reports. As this is a good coverage with
manual code inspection I'm quite sure we can trust the AI here.

The implementation looks sane. I'm a bit unsure about the comments in
the code, but can live with it.

Florian

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Jan Kiszka]

On 12.11.26 00:21, Florian Bezdeka wrote:
> On Wed, 2026-11-11 at 13:10 +0100, Jan Kiszka wrote:
>> [v2: rebased without changes, resent due to delivery issues of v1]
>>
> 
> While reviewing the risc-v implementation - and comparing it to all the
> other archs - arm included - I already noticed some problematic cases in
> arm.
> 
> I was able to address/fix some of them already, a couple of TODOs were
> still on my list.
> 
> 2/4 and 3/4 where on that list - with patches already prepared but
> untested, so not published yet - 4/4 was not on the radar yet, 1/4 came

Patch for is just because we touched the code already - it is
practically unused because there is no hardware out there which can
trigger it.

> up while looking at the other reports. As this is a good coverage with
> manual code inspection I'm quite sure we can trust the AI here.
> 
> The implementation looks sane. I'm a bit unsure about the comments in
> the code, but can live with it.
> 

I'm happy to shrink this down. Somewhere, I already did that, but the
rest was left to ease review.

FWIW: The related test case is in xenomai-3/next now, still waiting for
another update (and another kernel patch for x86). But the ARM side is
covered there, and the these patches on top of 6.18 fix the identified
issues the test otherwise complains about.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

>
> I will share the lengthy test case as well once I'm done with stripping
> it down further (if possible). What the tests already demonstrated is
> that unpatched kernels crash.
>
> These patches here are almost completely generated. One of my few
> contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
> of having oob_trap_regs as a nesting detector came from the AI, though.
>
> As usual, AI is still rather verbose in descriptions and comments. Some
> of them I already shortened, but most is still left. We can cut down
> further, but I would first of all like to have another review round.
>
> While doing that, keep in mind that AI tends to ignore issues left and
> right when being told to do a specific task. It may have simply missed
> further preexisting issues or even created new ones now. Watch out!
>

It looks like patches 1-3 have landed into v6.18.Y already, which means
that you are confident with those changes eventually.

-- 
Philippe.

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Florian Bezdeka]

On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
> > 
> > I will share the lengthy test case as well once I'm done with stripping
> > it down further (if possible). What the tests already demonstrated is
> > that unpatched kernels crash.
> > 
> > These patches here are almost completely generated. One of my few
> > contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
> > of having oob_trap_regs as a nesting detector came from the AI, though.
> > 
> > As usual, AI is still rather verbose in descriptions and comments. Some
> > of them I already shortened, but most is still left. We can cut down
> > further, but I would first of all like to have another review round.
> > 
> > While doing that, keep in mind that AI tends to ignore issues left and
> > right when being told to do a specific task. It may have simply missed
> > further preexisting issues or even created new ones now. Watch out!
> > 
> 
> It looks like patches 1-3 have landed into v6.18.Y already, which means
> that you are confident with those changes eventually.
> 

Those patches should not go anywhere until they reached the latest
development branch. The common "upstream first" rule.

Everything else will add a lot of confusion.

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Jan Kiszka]

On 12.11.26 12:05, Florian Bezdeka wrote:
> On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>
>>>
>>> I will share the lengthy test case as well once I'm done with stripping
>>> it down further (if possible). What the tests already demonstrated is
>>> that unpatched kernels crash.
>>>
>>> These patches here are almost completely generated. One of my few
>>> contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
>>> of having oob_trap_regs as a nesting detector came from the AI, though.
>>>
>>> As usual, AI is still rather verbose in descriptions and comments. Some
>>> of them I already shortened, but most is still left. We can cut down
>>> further, but I would first of all like to have another review round.
>>>
>>> While doing that, keep in mind that AI tends to ignore issues left and
>>> right when being told to do a specific task. It may have simply missed
>>> further preexisting issues or even created new ones now. Watch out!
>>>
>>
>> It looks like patches 1-3 have landed into v6.18.Y already, which means
>> that you are confident with those changes eventually.
>>
> 
> Those patches should not go anywhere until they reached the latest
> development branch. The common "upstream first" rule.
> 
> Everything else will add a lot of confusion.

The v6.18 application was experimental, to validate that the test suite
passes on real hardware when all issues are addressed. Nothing is
official in rebase branches until it is tagged, including those patches.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Florian Bezdeka]

On Thu, 2026-11-12 at 12:16 +0100, Jan Kiszka wrote:
> On 12.11.26 12:05, Florian Bezdeka wrote:
> > On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
> > > Jan Kiszka <jan.kiszka@siemens.com> writes:
> > > 
> > > > 
> > > > I will share the lengthy test case as well once I'm done with stripping
> > > > it down further (if possible). What the tests already demonstrated is
> > > > that unpatched kernels crash.
> > > > 
> > > > These patches here are almost completely generated. One of my few
> > > > contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
> > > > of having oob_trap_regs as a nesting detector came from the AI, though.
> > > > 
> > > > As usual, AI is still rather verbose in descriptions and comments. Some
> > > > of them I already shortened, but most is still left. We can cut down
> > > > further, but I would first of all like to have another review round.
> > > > 
> > > > While doing that, keep in mind that AI tends to ignore issues left and
> > > > right when being told to do a specific task. It may have simply missed
> > > > further preexisting issues or even created new ones now. Watch out!
> > > > 
> > > 
> > > It looks like patches 1-3 have landed into v6.18.Y already, which means
> > > that you are confident with those changes eventually.
> > > 
> > 
> > Those patches should not go anywhere until they reached the latest
> > development branch. The common "upstream first" rule.
> > 
> > Everything else will add a lot of confusion.
> 
> The v6.18 application was experimental, to validate that the test suite
> passes on real hardware when all issues are addressed. Nothing is
> official in rebase branches until it is tagged, including those patches.
> 
> Jan
> 

Why not just push out a wip/ prefixed branch? That does not require to
temporary update branches looked at by different / more people.

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Jan Kiszka]

On 12.11.26 12:25, Florian Bezdeka wrote:
> On Thu, 2026-11-12 at 12:16 +0100, Jan Kiszka wrote:
>> On 12.11.26 12:05, Florian Bezdeka wrote:
>>> On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>
>>>>>
>>>>> I will share the lengthy test case as well once I'm done with stripping
>>>>> it down further (if possible). What the tests already demonstrated is
>>>>> that unpatched kernels crash.
>>>>>
>>>>> These patches here are almost completely generated. One of my few
>>>>> contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
>>>>> of having oob_trap_regs as a nesting detector came from the AI, though.
>>>>>
>>>>> As usual, AI is still rather verbose in descriptions and comments. Some
>>>>> of them I already shortened, but most is still left. We can cut down
>>>>> further, but I would first of all like to have another review round.
>>>>>
>>>>> While doing that, keep in mind that AI tends to ignore issues left and
>>>>> right when being told to do a specific task. It may have simply missed
>>>>> further preexisting issues or even created new ones now. Watch out!
>>>>>
>>>>
>>>> It looks like patches 1-3 have landed into v6.18.Y already, which means
>>>> that you are confident with those changes eventually.
>>>>
>>>
>>> Those patches should not go anywhere until they reached the latest
>>> development branch. The common "upstream first" rule.
>>>
>>> Everything else will add a lot of confusion.
>>
>> The v6.18 application was experimental, to validate that the test suite
>> passes on real hardware when all issues are addressed. Nothing is
>> official in rebase branches until it is tagged, including those patches.
>>
>> Jan
>>
> 
> Why not just push out a wip/ prefixed branch? That does not require to
> temporary update branches looked at by different / more people.

CI is not picking up such branches.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Florian Bezdeka]

On Thu, 2026-11-12 at 12:30 +0100, Jan Kiszka wrote:
> On 12.11.26 12:25, Florian Bezdeka wrote:
> > On Thu, 2026-11-12 at 12:16 +0100, Jan Kiszka wrote:
> > > On 12.11.26 12:05, Florian Bezdeka wrote:
> > > > On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
> > > > > Jan Kiszka <jan.kiszka@siemens.com> writes:
> > > > > 
> > > > > > 
> > > > > > I will share the lengthy test case as well once I'm done with stripping
> > > > > > it down further (if possible). What the tests already demonstrated is
> > > > > > that unpatched kernels crash.
> > > > > > 
> > > > > > These patches here are almost completely generated. One of my few
> > > > > > contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
> > > > > > of having oob_trap_regs as a nesting detector came from the AI, though.
> > > > > > 
> > > > > > As usual, AI is still rather verbose in descriptions and comments. Some
> > > > > > of them I already shortened, but most is still left. We can cut down
> > > > > > further, but I would first of all like to have another review round.
> > > > > > 
> > > > > > While doing that, keep in mind that AI tends to ignore issues left and
> > > > > > right when being told to do a specific task. It may have simply missed
> > > > > > further preexisting issues or even created new ones now. Watch out!
> > > > > > 
> > > > > 
> > > > > It looks like patches 1-3 have landed into v6.18.Y already, which means
> > > > > that you are confident with those changes eventually.
> > > > > 
> > > > 
> > > > Those patches should not go anywhere until they reached the latest
> > > > development branch. The common "upstream first" rule.
> > > > 
> > > > Everything else will add a lot of confusion.
> > > 
> > > The v6.18 application was experimental, to validate that the test suite
> > > passes on real hardware when all issues are addressed. Nothing is
> > > official in rebase branches until it is tagged, including those patches.
> > > 
> > > Jan
> > > 
> > 
> > Why not just push out a wip/ prefixed branch? That does not require to
> > temporary update branches looked at by different / more people.
> 
> CI is not picking up such branches.
> 

Which is OK. Those branches should be tested only when requested
manually. The "internal" infrastructure has such a feature, while the
public one is missing that.

Upstreaming was not considered yet as it highly reworked the xenomai-
images project. But maybe it's of interest now.

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Jan Kiszka]

On 12.11.26 12:39, Florian Bezdeka wrote:
> On Thu, 2026-11-12 at 12:30 +0100, Jan Kiszka wrote:
>> On 12.11.26 12:25, Florian Bezdeka wrote:
>>> On Thu, 2026-11-12 at 12:16 +0100, Jan Kiszka wrote:
>>>> On 12.11.26 12:05, Florian Bezdeka wrote:
>>>>> On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>
>>>>>>>
>>>>>>> I will share the lengthy test case as well once I'm done with stripping
>>>>>>> it down further (if possible). What the tests already demonstrated is
>>>>>>> that unpatched kernels crash.
>>>>>>>
>>>>>>> These patches here are almost completely generated. One of my few
>>>>>>> contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
>>>>>>> of having oob_trap_regs as a nesting detector came from the AI, though.
>>>>>>>
>>>>>>> As usual, AI is still rather verbose in descriptions and comments. Some
>>>>>>> of them I already shortened, but most is still left. We can cut down
>>>>>>> further, but I would first of all like to have another review round.
>>>>>>>
>>>>>>> While doing that, keep in mind that AI tends to ignore issues left and
>>>>>>> right when being told to do a specific task. It may have simply missed
>>>>>>> further preexisting issues or even created new ones now. Watch out!
>>>>>>>
>>>>>>
>>>>>> It looks like patches 1-3 have landed into v6.18.Y already, which means
>>>>>> that you are confident with those changes eventually.
>>>>>>
>>>>>
>>>>> Those patches should not go anywhere until they reached the latest
>>>>> development branch. The common "upstream first" rule.
>>>>>
>>>>> Everything else will add a lot of confusion.
>>>>
>>>> The v6.18 application was experimental, to validate that the test suite
>>>> passes on real hardware when all issues are addressed. Nothing is
>>>> official in rebase branches until it is tagged, including those patches.
>>>>
>>>> Jan
>>>>
>>>
>>> Why not just push out a wip/ prefixed branch? That does not require to
>>> temporary update branches looked at by different / more people.
>>
>> CI is not picking up such branches.
>>
> 
> Which is OK. Those branches should be tested only when requested
> manually. The "internal" infrastructure has such a feature, while the
> public one is missing that.
> 
> Upstreaming was not considered yet as it highly reworked the xenomai-
> images project. But maybe it's of interest now.
> 

I'm not using anything internal. If you have a patch for the official
one, please submit.

But pushing to -rebase is also not a big deal because it is, well,
rebasing, not stable.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 12.11.26 12:39, Florian Bezdeka wrote:
>> On Thu, 2026-11-12 at 12:30 +0100, Jan Kiszka wrote:
>>> On 12.11.26 12:25, Florian Bezdeka wrote:
>>>> On Thu, 2026-11-12 at 12:16 +0100, Jan Kiszka wrote:
>>>>> On 12.11.26 12:05, Florian Bezdeka wrote:
>>>>>> On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>
>>>>>>>>
>>>>>>>> I will share the lengthy test case as well once I'm done with stripping
>>>>>>>> it down further (if possible). What the tests already demonstrated is
>>>>>>>> that unpatched kernels crash.
>>>>>>>>
>>>>>>>> These patches here are almost completely generated. One of my few
>>>>>>>> contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
>>>>>>>> of having oob_trap_regs as a nesting detector came from the AI, though.
>>>>>>>>
>>>>>>>> As usual, AI is still rather verbose in descriptions and comments. Some
>>>>>>>> of them I already shortened, but most is still left. We can cut down
>>>>>>>> further, but I would first of all like to have another review round.
>>>>>>>>
>>>>>>>> While doing that, keep in mind that AI tends to ignore issues left and
>>>>>>>> right when being told to do a specific task. It may have simply missed
>>>>>>>> further preexisting issues or even created new ones now. Watch out!
>>>>>>>>
>>>>>>>
>>>>>>> It looks like patches 1-3 have landed into v6.18.Y already, which means
>>>>>>> that you are confident with those changes eventually.
>>>>>>>
>>>>>>
>>>>>> Those patches should not go anywhere until they reached the latest
>>>>>> development branch. The common "upstream first" rule.
>>>>>>
>>>>>> Everything else will add a lot of confusion.
>>>>>
>>>>> The v6.18 application was experimental, to validate that the test suite
>>>>> passes on real hardware when all issues are addressed. Nothing is
>>>>> official in rebase branches until it is tagged, including those patches.
>>>>>
>>>>> Jan
>>>>>
>>>>
>>>> Why not just push out a wip/ prefixed branch? That does not require to
>>>> temporary update branches looked at by different / more people.
>>>
>>> CI is not picking up such branches.
>>>
>> 
>> Which is OK. Those branches should be tested only when requested
>> manually. The "internal" infrastructure has such a feature, while the
>> public one is missing that.
>> 
>> Upstreaming was not considered yet as it highly reworked the xenomai-
>> images project. But maybe it's of interest now.
>> 
>
> I'm not using anything internal. If you have a patch for the official
> one, please submit.
>
> But pushing to -rebase is also not a big deal because it is, well,
> rebasing, not stable.
>

The dovetail rebase branches feed the evl trees though, which follow a
rebasing model for a reason. Although I'm not concerned by the specific
patches I mentioned earlier which look sane so far (review is still
ongoing), let's keep in mind that dovetail rebase branches are not the
right place for unstable work. As Florian pointed out, wip/ should
preferred for this.

-- 
Philippe.

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Jan Kiszka]

On 12.11.26 13:59, Philippe Gerum wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> On 12.11.26 12:39, Florian Bezdeka wrote:
>>> On Thu, 2026-11-12 at 12:30 +0100, Jan Kiszka wrote:
>>>> On 12.11.26 12:25, Florian Bezdeka wrote:
>>>>> On Thu, 2026-11-12 at 12:16 +0100, Jan Kiszka wrote:
>>>>>> On 12.11.26 12:05, Florian Bezdeka wrote:
>>>>>>> On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I will share the lengthy test case as well once I'm done with stripping
>>>>>>>>> it down further (if possible). What the tests already demonstrated is
>>>>>>>>> that unpatched kernels crash.
>>>>>>>>>
>>>>>>>>> These patches here are almost completely generated. One of my few
>>>>>>>>> contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
>>>>>>>>> of having oob_trap_regs as a nesting detector came from the AI, though.
>>>>>>>>>
>>>>>>>>> As usual, AI is still rather verbose in descriptions and comments. Some
>>>>>>>>> of them I already shortened, but most is still left. We can cut down
>>>>>>>>> further, but I would first of all like to have another review round.
>>>>>>>>>
>>>>>>>>> While doing that, keep in mind that AI tends to ignore issues left and
>>>>>>>>> right when being told to do a specific task. It may have simply missed
>>>>>>>>> further preexisting issues or even created new ones now. Watch out!
>>>>>>>>>
>>>>>>>>
>>>>>>>> It looks like patches 1-3 have landed into v6.18.Y already, which means
>>>>>>>> that you are confident with those changes eventually.
>>>>>>>>
>>>>>>>
>>>>>>> Those patches should not go anywhere until they reached the latest
>>>>>>> development branch. The common "upstream first" rule.
>>>>>>>
>>>>>>> Everything else will add a lot of confusion.
>>>>>>
>>>>>> The v6.18 application was experimental, to validate that the test suite
>>>>>> passes on real hardware when all issues are addressed. Nothing is
>>>>>> official in rebase branches until it is tagged, including those patches.
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>
>>>>> Why not just push out a wip/ prefixed branch? That does not require to
>>>>> temporary update branches looked at by different / more people.
>>>>
>>>> CI is not picking up such branches.
>>>>
>>>
>>> Which is OK. Those branches should be tested only when requested
>>> manually. The "internal" infrastructure has such a feature, while the
>>> public one is missing that.
>>>
>>> Upstreaming was not considered yet as it highly reworked the xenomai-
>>> images project. But maybe it's of interest now.
>>>
>>
>> I'm not using anything internal. If you have a patch for the official
>> one, please submit.
>>
>> But pushing to -rebase is also not a big deal because it is, well,
>> rebasing, not stable.
>>
> 
> The dovetail rebase branches feed the evl trees though, which follow a
> rebasing model for a reason. Although I'm not concerned by the specific
> patches I mentioned earlier which look sane so far (review is still
> ongoing), let's keep in mind that dovetail rebase branches are not the
> right place for unstable work. As Florian pointed out, wip/ should
> preferred for this.

Rebase branches were and are not stable until they are tested. This is
what they exist for. Once testing passed, we tag. This is also how I run
all the stable versions I maintain. In most cased, the tagging goes
straight on top, but I already had to fix up untagged branches in the
past. Or rebase them once more because of further upstream releases.

Now, if you ever tagged evl branches earlier than dovetail branches,
that should be avoided in the future.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 12.11.26 13:59, Philippe Gerum wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>>> On 12.11.26 12:39, Florian Bezdeka wrote:
>>>> On Thu, 2026-11-12 at 12:30 +0100, Jan Kiszka wrote:
>>>>> On 12.11.26 12:25, Florian Bezdeka wrote:
>>>>>> On Thu, 2026-11-12 at 12:16 +0100, Jan Kiszka wrote:
>>>>>>> On 12.11.26 12:05, Florian Bezdeka wrote:
>>>>>>>> On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
>>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I will share the lengthy test case as well once I'm done with stripping
>>>>>>>>>> it down further (if possible). What the tests already demonstrated is
>>>>>>>>>> that unpatched kernels crash.
>>>>>>>>>>
>>>>>>>>>> These patches here are almost completely generated. One of my few
>>>>>>>>>> contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
>>>>>>>>>> of having oob_trap_regs as a nesting detector came from the AI, though.
>>>>>>>>>>
>>>>>>>>>> As usual, AI is still rather verbose in descriptions and comments. Some
>>>>>>>>>> of them I already shortened, but most is still left. We can cut down
>>>>>>>>>> further, but I would first of all like to have another review round.
>>>>>>>>>>
>>>>>>>>>> While doing that, keep in mind that AI tends to ignore issues left and
>>>>>>>>>> right when being told to do a specific task. It may have simply missed
>>>>>>>>>> further preexisting issues or even created new ones now. Watch out!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It looks like patches 1-3 have landed into v6.18.Y already, which means
>>>>>>>>> that you are confident with those changes eventually.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Those patches should not go anywhere until they reached the latest
>>>>>>>> development branch. The common "upstream first" rule.
>>>>>>>>
>>>>>>>> Everything else will add a lot of confusion.
>>>>>>>
>>>>>>> The v6.18 application was experimental, to validate that the test suite
>>>>>>> passes on real hardware when all issues are addressed. Nothing is
>>>>>>> official in rebase branches until it is tagged, including those patches.
>>>>>>>
>>>>>>> Jan
>>>>>>>
>>>>>>
>>>>>> Why not just push out a wip/ prefixed branch? That does not require to
>>>>>> temporary update branches looked at by different / more people.
>>>>>
>>>>> CI is not picking up such branches.
>>>>>
>>>>
>>>> Which is OK. Those branches should be tested only when requested
>>>> manually. The "internal" infrastructure has such a feature, while the
>>>> public one is missing that.
>>>>
>>>> Upstreaming was not considered yet as it highly reworked the xenomai-
>>>> images project. But maybe it's of interest now.
>>>>
>>>
>>> I'm not using anything internal. If you have a patch for the official
>>> one, please submit.
>>>
>>> But pushing to -rebase is also not a big deal because it is, well,
>>> rebasing, not stable.
>>>
>> 
>> The dovetail rebase branches feed the evl trees though, which follow a
>> rebasing model for a reason. Although I'm not concerned by the specific
>> patches I mentioned earlier which look sane so far (review is still
>> ongoing), let's keep in mind that dovetail rebase branches are not the
>> right place for unstable work. As Florian pointed out, wip/ should
>> preferred for this.
>
> Rebase branches were and are not stable until they are tested. This is
> what they exist for.

No, they don't. Rebase branches are only a workflow for evl which do not
assume that code might be unstable in there, only accepting that bugs do
exist.

> Once testing passed, we tag. This is also how I run
> all the stable versions I maintain. In most cased, the tagging goes
> straight on top, but I already had to fix up untagged branches in the
> past. Or rebase them once more because of further upstream releases.
>
> Now, if you ever tagged evl branches earlier than dovetail branches,
> that should be avoided in the future.

I'm unsure why the tagging issue is brought up, this is not the point
which is being discussed. The point is to refrain from changing the
semantics underlying the rebase branch arbitrarily, only to find out
that this may break the evl development that sparked the dovetail
development in the first place, nearly ten years ago.

I'm generally ok for improving the process, like getting help from an
LLM for the mechanical part of the maintenance, but let's do this with
every stakeholder on board, participating to the decision.

-- 
Philippe.

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Jan Kiszka]

On 12.11.26 14:49, Philippe Gerum wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> On 12.11.26 13:59, Philippe Gerum wrote:
>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>
>>>> On 12.11.26 12:39, Florian Bezdeka wrote:
>>>>> On Thu, 2026-11-12 at 12:30 +0100, Jan Kiszka wrote:
>>>>>> On 12.11.26 12:25, Florian Bezdeka wrote:
>>>>>>> On Thu, 2026-11-12 at 12:16 +0100, Jan Kiszka wrote:
>>>>>>>> On 12.11.26 12:05, Florian Bezdeka wrote:
>>>>>>>>> On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
>>>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I will share the lengthy test case as well once I'm done with stripping
>>>>>>>>>>> it down further (if possible). What the tests already demonstrated is
>>>>>>>>>>> that unpatched kernels crash.
>>>>>>>>>>>
>>>>>>>>>>> These patches here are almost completely generated. One of my few
>>>>>>>>>>> contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
>>>>>>>>>>> of having oob_trap_regs as a nesting detector came from the AI, though.
>>>>>>>>>>>
>>>>>>>>>>> As usual, AI is still rather verbose in descriptions and comments. Some
>>>>>>>>>>> of them I already shortened, but most is still left. We can cut down
>>>>>>>>>>> further, but I would first of all like to have another review round.
>>>>>>>>>>>
>>>>>>>>>>> While doing that, keep in mind that AI tends to ignore issues left and
>>>>>>>>>>> right when being told to do a specific task. It may have simply missed
>>>>>>>>>>> further preexisting issues or even created new ones now. Watch out!
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It looks like patches 1-3 have landed into v6.18.Y already, which means
>>>>>>>>>> that you are confident with those changes eventually.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Those patches should not go anywhere until they reached the latest
>>>>>>>>> development branch. The common "upstream first" rule.
>>>>>>>>>
>>>>>>>>> Everything else will add a lot of confusion.
>>>>>>>>
>>>>>>>> The v6.18 application was experimental, to validate that the test suite
>>>>>>>> passes on real hardware when all issues are addressed. Nothing is
>>>>>>>> official in rebase branches until it is tagged, including those patches.
>>>>>>>>
>>>>>>>> Jan
>>>>>>>>
>>>>>>>
>>>>>>> Why not just push out a wip/ prefixed branch? That does not require to
>>>>>>> temporary update branches looked at by different / more people.
>>>>>>
>>>>>> CI is not picking up such branches.
>>>>>>
>>>>>
>>>>> Which is OK. Those branches should be tested only when requested
>>>>> manually. The "internal" infrastructure has such a feature, while the
>>>>> public one is missing that.
>>>>>
>>>>> Upstreaming was not considered yet as it highly reworked the xenomai-
>>>>> images project. But maybe it's of interest now.
>>>>>
>>>>
>>>> I'm not using anything internal. If you have a patch for the official
>>>> one, please submit.
>>>>
>>>> But pushing to -rebase is also not a big deal because it is, well,
>>>> rebasing, not stable.
>>>>
>>>
>>> The dovetail rebase branches feed the evl trees though, which follow a
>>> rebasing model for a reason. Although I'm not concerned by the specific
>>> patches I mentioned earlier which look sane so far (review is still
>>> ongoing), let's keep in mind that dovetail rebase branches are not the
>>> right place for unstable work. As Florian pointed out, wip/ should
>>> preferred for this.
>>
>> Rebase branches were and are not stable until they are tested. This is
>> what they exist for.
> 
> No, they don't. Rebase branches are only a workflow for evl which do not
> assume that code might be unstable in there, only accepting that bugs do
> exist.
> 
>> Once testing passed, we tag. This is also how I run
>> all the stable versions I maintain. In most cased, the tagging goes
>> straight on top, but I already had to fix up untagged branches in the
>> past. Or rebase them once more because of further upstream releases.
>>
>> Now, if you ever tagged evl branches earlier than dovetail branches,
>> that should be avoided in the future.
> 
> I'm unsure why the tagging issue is brought up, this is not the point
> which is being discussed. The point is to refrain from changing the
> semantics underlying the rebase branch arbitrarily, only to find out
> that this may break the evl development that sparked the dovetail
> development in the first place, nearly ten years ago.
> 
> I'm generally ok for improving the process, like getting help from an
> LLM for the mechanical part of the maintenance, but let's do this with
> every stakeholder on board, participating to the decision.
> 

Yes, we need to align on this. Do you have your workflow documented
anywhere? Then blame it on me that I didn't read that. I only followed
intuitively reasonable patterns for many years now to ensure that
dovetail is broadly tested and based on recent stable versions before it
is released.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 12.11.26 14:49, Philippe Gerum wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>>> On 12.11.26 13:59, Philippe Gerum wrote:
>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>
>>>>> On 12.11.26 12:39, Florian Bezdeka wrote:
>>>>>> On Thu, 2026-11-12 at 12:30 +0100, Jan Kiszka wrote:
>>>>>>> On 12.11.26 12:25, Florian Bezdeka wrote:
>>>>>>>> On Thu, 2026-11-12 at 12:16 +0100, Jan Kiszka wrote:
>>>>>>>>> On 12.11.26 12:05, Florian Bezdeka wrote:
>>>>>>>>>> On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
>>>>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I will share the lengthy test case as well once I'm done with stripping
>>>>>>>>>>>> it down further (if possible). What the tests already demonstrated is
>>>>>>>>>>>> that unpatched kernels crash.
>>>>>>>>>>>>
>>>>>>>>>>>> These patches here are almost completely generated. One of my few
>>>>>>>>>>>> contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
>>>>>>>>>>>> of having oob_trap_regs as a nesting detector came from the AI, though.
>>>>>>>>>>>>
>>>>>>>>>>>> As usual, AI is still rather verbose in descriptions and comments. Some
>>>>>>>>>>>> of them I already shortened, but most is still left. We can cut down
>>>>>>>>>>>> further, but I would first of all like to have another review round.
>>>>>>>>>>>>
>>>>>>>>>>>> While doing that, keep in mind that AI tends to ignore issues left and
>>>>>>>>>>>> right when being told to do a specific task. It may have simply missed
>>>>>>>>>>>> further preexisting issues or even created new ones now. Watch out!
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It looks like patches 1-3 have landed into v6.18.Y already, which means
>>>>>>>>>>> that you are confident with those changes eventually.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Those patches should not go anywhere until they reached the latest
>>>>>>>>>> development branch. The common "upstream first" rule.
>>>>>>>>>>
>>>>>>>>>> Everything else will add a lot of confusion.
>>>>>>>>>
>>>>>>>>> The v6.18 application was experimental, to validate that the test suite
>>>>>>>>> passes on real hardware when all issues are addressed. Nothing is
>>>>>>>>> official in rebase branches until it is tagged, including those patches.
>>>>>>>>>
>>>>>>>>> Jan
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why not just push out a wip/ prefixed branch? That does not require to
>>>>>>>> temporary update branches looked at by different / more people.
>>>>>>>
>>>>>>> CI is not picking up such branches.
>>>>>>>
>>>>>>
>>>>>> Which is OK. Those branches should be tested only when requested
>>>>>> manually. The "internal" infrastructure has such a feature, while the
>>>>>> public one is missing that.
>>>>>>
>>>>>> Upstreaming was not considered yet as it highly reworked the xenomai-
>>>>>> images project. But maybe it's of interest now.
>>>>>>
>>>>>
>>>>> I'm not using anything internal. If you have a patch for the official
>>>>> one, please submit.
>>>>>
>>>>> But pushing to -rebase is also not a big deal because it is, well,
>>>>> rebasing, not stable.
>>>>>
>>>>
>>>> The dovetail rebase branches feed the evl trees though, which follow a
>>>> rebasing model for a reason. Although I'm not concerned by the specific
>>>> patches I mentioned earlier which look sane so far (review is still
>>>> ongoing), let's keep in mind that dovetail rebase branches are not the
>>>> right place for unstable work. As Florian pointed out, wip/ should
>>>> preferred for this.
>>>
>>> Rebase branches were and are not stable until they are tested. This is
>>> what they exist for.
>> 
>> No, they don't. Rebase branches are only a workflow for evl which do not
>> assume that code might be unstable in there, only accepting that bugs do
>> exist.
>> 
>>> Once testing passed, we tag. This is also how I run
>>> all the stable versions I maintain. In most cased, the tagging goes
>>> straight on top, but I already had to fix up untagged branches in the
>>> past. Or rebase them once more because of further upstream releases.
>>>
>>> Now, if you ever tagged evl branches earlier than dovetail branches,
>>> that should be avoided in the future.
>> 
>> I'm unsure why the tagging issue is brought up, this is not the point
>> which is being discussed. The point is to refrain from changing the
>> semantics underlying the rebase branch arbitrarily, only to find out
>> that this may break the evl development that sparked the dovetail
>> development in the first place, nearly ten years ago.
>> 
>> I'm generally ok for improving the process, like getting help from an
>> LLM for the mechanical part of the maintenance, but let's do this with
>> every stakeholder on board, participating to the decision.
>> 
>
> Yes, we need to align on this. Do you have your workflow documented
> anywhere?

Terser on the kernel side compared to libevl unfortunately, written
years ago but the basics did not change.

https://v4.xenomai.org/devprocess/index.html

> Then blame it on me that I didn't read that. I only followed
> intuitively reasonable patterns for many years now to ensure that
> dovetail is broadly tested and based on recent stable versions before it
> is released.
>

I do acknowledge this as a valuable effort, of course. We just need to
keep flexibility at the other end of the line as well, because as you
already know, we have to deal with out-of-tree issues vs upstream code
churn, an integration effort ongoing on the evl side in order to align
as intimately as possible with upstream by reusing its infrastructure,
and only few resources to do all of that.

So let's have an open conversation with anyone interested in
participating to it, about what can be improved in the existing process
- which was laid out in the early stages of the evl development when the
only dovetail user was evl. What made it flexible once may have become a
liability in some aspects, we can and should address these issues.

-- 
Philippe.