Re: [PATCH Dovetail 2/2] arm64: irq_pipeline: Fix the demotion checks for el0 and el1 IRQs

On Tue, 2026-02-17 at 09:41 +0100, Philippe Gerum wrote:
> > Comparing with x86 again, I think that my proposal is "correct" in terms
> > of identical to what x86 does. Do all architectures have a gap here?
> 
> x86 has a single implementation for both user and kernel preemption
> paths, arm64 has two since the privilege level is explicitly stated by
> the irq handler being called, but this still must translate identically
> logically speaking. Your implementation is missing the kernel preemption
> path after demotion.
> 
> i.e. when checking for running_oob() || irqs_disabled(), the cases
> covered are:
> 
> (1) in-band user path on entry (implies !irqs_disabled())
> (2) oob user path on entry (might be demoted)
> (3) (virtually) stalled in-band kernel path on entry (implies no reschedule,
>   filtered out by irqentry_exit())
> (4) oob kernel path on entry (might be demoted)
> 
> Therefore, with your patch in, el1 is now missing (4).

Right, but I'm wondering if x86 ignores this case as well.

After demotion of a oob kernel path entry, user_mode() should still be
false - bypassing the call to irqentry_exit_to_user_mode() - No?