On 28/08/2026 8:01 am, Jan Beulich wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2304,7 +2304,7 @@ void asmlinkage entry_from_pv(struct cpu
> case X86_ET_HW_EXC:
> switch ( vec )
> {
> - case X86_EXC_DF: return do_double_fault(regs);
> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */
> case X86_EXC_MC: return do_machine_check(regs);
> }
> break;
> @@ -2615,7 +2615,7 @@ void asmlinkage entry_from_xen(struct cp
> case X86_ET_HW_EXC:
> switch ( regs->fred_ss.vector )
> {
> - case X86_EXC_DF: return do_double_fault(regs);
> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */
> case X86_EXC_MC: return do_machine_check(regs);
> }
> break;
>
For starters you're missing a break, and the only reason this isn't a
compile error is the trailing comment. Second, it's a tailcall anyway.
There really is nothing unreachable anywhere in this construct.
But by far the most important, it the singular noreturn attribute on
do_double_fault() (elsewhere, and not visible when reading these two
functions) which is preventing #DF falling into #MC. This introduces
fragility which did not exist previously.
do_double_fault() would conditionally return if we ever got around to
fixing espfix64.
So no - I'm going to insist that Eclair is taught to accept "return
some_noreturn_fn();" as intentional. It is objectively less fragile
than the MISRA-preferred option.
~Andrew
