From: Philippe Gerum <rpm@xenomai.org>
To: Florian Bezdeka <florian.bezdeka@siemens.com>
Cc: Xenomai <xenomai@lists.linux.dev>, Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [PATCH Dovetail 2/2] arm64: irq_pipeline: Fix the demotion checks for el0 and el1 IRQs
Date: Tue, 17 Feb 2026 09:49:50 +0100 [thread overview]
Message-ID: <878qcrah5d.fsf@xenomai.org> (raw)
In-Reply-To: <9e12c4a73df2d24dd1b39ab196b0112cb4e7e6ef.camel@siemens.com> (Florian Bezdeka's message of "Tue, 17 Feb 2026 09:24:31 +0100")
Florian Bezdeka <florian.bezdeka@siemens.com> writes:
> On Tue, 2026-02-17 at 09:12 +0100, Florian Bezdeka wrote:
>> On Tue, 2026-02-17 at 09:00 +0100, Philippe Gerum wrote:
>> > Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>> >
>> > > While reviewing some of the low level pipeline code I realized that
>> > > the checks for task demotion are wrong on arm64.
>> > >
>> > > el0: The demotion check was missing in the oob case. We have to check
>> > > for running_inband() only as user_mode(regs) will always be true.
>> > > We are serving an IRQ over el0, so application / user mode.
>> > >
>> > > el1: The demotion check was unnecessary and "inactive" as
>> > > user_mode(regs) is never true on el1, we are serving an IRQ over
>> > > kernel mode.
>> > >
>> >
>> > If the demotion happens from el1, you still want to check for a
>> > rescheduling opportunity (i.e. kernel preemption case).
>> >
>> > > Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
>> > > ---
>> > > arch/arm64/kernel/entry-common.c | 8 ++++----
>> > > 1 file changed, 4 insertions(+), 4 deletions(-)
>> > >
>> > > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
>> > > index 07fa70713ce04eaf3df9223354babcecde923280..9c99eb3d18c459a90e1f7ce4e4c307e235e457a2 100644
>> > > --- a/arch/arm64/kernel/entry-common.c
>> > > +++ b/arch/arm64/kernel/entry-common.c
>> > > @@ -73,6 +73,10 @@ static noinstr void arm64_pipeline_el0_irq(struct pt_regs *regs,
>> > > do_interrupt_handler(regs, handler);
>> > > /* Done, unwind now. */
>> > > handle_irq_pipelined_finish(prevd, regs);
>> > > + if (running_inband()) {
>> > > + stall_inband_nocheck();
>> > > + irqentry_exit_to_user_mode(regs);
>> > > + }
>> > > instrumentation_end();
>> > > arm64_exit_to_user_mode(regs);
>> > > }
>> > > @@ -90,10 +94,6 @@ static noinstr void arm64_pipeline_el1_irq(struct pt_regs *regs,
>> > > prevd = handle_irq_pipelined_prepare(regs);
>> > > do_interrupt_handler(regs, handler);
>> > > handle_irq_pipelined_finish(prevd, regs);
>> > > - if (running_inband() && user_mode(regs)) {
>> > > - stall_inband_nocheck();
>> > > - irqentry_exit_to_user_mode(regs);
>> > > - }
>> > > instrumentation_end();
>> > > mte_check_tfsr_exit();
>> > > return;
>> >
>> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
>> > index e0227d467cef4..770fc4059e083 100644
>> > --- a/arch/arm64/kernel/entry-common.c
>> > +++ b/arch/arm64/kernel/entry-common.c
>> > @@ -90,10 +90,8 @@ static noinstr void arm64_pipeline_el1_irq(struct pt_regs *regs,
>> > prevd = handle_irq_pipelined_prepare(regs);
>> > do_interrupt_handler(regs, handler);
>> > handle_irq_pipelined_finish(prevd, regs);
>> > - if (running_inband() && user_mode(regs)) {
>> > - stall_inband_nocheck();
>> > - irqentry_exit_to_user_mode(regs);
>> > - }
>> > + if (running_inband())
>> > + goto out_irqentry;
>> > instrumentation_end();
>> > mte_check_tfsr_exit();
>> > return;
>> > @@ -109,6 +107,7 @@ static noinstr void arm64_pipeline_el1_irq(struct pt_regs *regs,
>> > trace_hardirqs_on();
>> > unstall_inband_nocheck();
>> > handle_irq_pipelined_finish(prevd, regs);
>> > +out_irqentry:
>> > stall_inband_nocheck();
>> > trace_hardirqs_off();
>> > instrumentation_end();
>> >
>>
>> That would look a bit imbalanced. We would have one additional
>> trace_hardirqs_off() and one irqentry_exit() call without counterparts.
>>
>> Is that really OK? Testing...
>
> Nope, doesn't boot up on my arm64 qemu.
>
This patch runs fine on my end, survives the full evl test suite,
including the hectic test. Which kernel preemption model are you using?
mine is this one:
Linux qemu-arm64-evl 6.18.7-00979-gb2cf536d0898-dirty #286 SMP PREEMPT_RT EVL Tue Feb 17 09:45:50 CET 2026 aarch64 GNU/Linux
--
Philippe.
next prev parent reply other threads:[~2026-02-17 8:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-16 19:05 [PATCH Dovetail 0/2] Dovetail: Fix for arm64 IRQ pipelining, API for co-kernels Florian Bezdeka
2026-02-16 19:05 ` [PATCH Dovetail 1/2] dovetail: genirq: Add request_percpu_irq_affinity_flags() Florian Bezdeka
2026-02-16 19:05 ` [PATCH Dovetail 2/2] arm64: irq_pipeline: Fix the demotion checks for el0 and el1 IRQs Florian Bezdeka
2026-02-17 8:00 ` Philippe Gerum
2026-02-17 8:12 ` Florian Bezdeka
2026-02-17 8:24 ` Florian Bezdeka
2026-02-17 8:41 ` Philippe Gerum
2026-02-17 9:16 ` Florian Bezdeka
2026-02-17 9:40 ` Philippe Gerum
2026-02-17 10:11 ` Philippe Gerum
2026-02-17 11:23 ` Florian Bezdeka
2026-02-17 13:31 ` Philippe Gerum
2026-02-17 14:37 ` Florian Bezdeka
2026-02-17 8:49 ` Philippe Gerum [this message]
2026-02-17 9:01 ` Florian Bezdeka
2026-02-17 9:10 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878qcrah5d.fsf@xenomai.org \
--to=rpm@xenomai.org \
--cc=florian.bezdeka@siemens.com \
--cc=jan.kiszka@siemens.com \
--cc=xenomai@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox