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

[Philippe Gerum <rpm@xenomai.org>]

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

> 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?

Yes, x86 assumes that a kernel path demoted to in-band is going to cross
an IRQ synchronization point shortly after on return to the preempted
context. Now, with hindsight, the question is: are we 100% certain of
that? Any real (hw) IRQ over the in-band stage would trigger the
synchronization as expected, but a synthetic one posted from the oob
stage might linger if this assumption ends up being wrong. I need to
have a second look at this code.

-- 
Philippe.