Re: [PATCH dovetail] irq_pipeline: synchronize inband IRQ log in exit_to_user_mode_prepare()
Florian Bezdeka <[email protected]>
| Newsgroups | dev.linux.lists.xenomai |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 2026-02-16 at 15:30 +0100, Philippe Gerum wrote: > Florian Bezdeka <[email protected]> writes: > > > On 2/14/26 12:39, Tobias Schaffner wrote: > > > Architectures using the generic handle_irq_pipelined() path do not > > > > arm64 and x86 are not using that, so the only arch left is arm. > > See below... > > > > > synchronize the inband IRQ log in handle_irq_pipelined_finish() > > > because inband is still stalled from irqentry_enter() when it gets > > > called. > > > > I think the real issue / correct wording is: > > > > _TIF_WORK is left pending on IRQ exit. > > > > More precisely, some IRQs might be logged for the in-band stage (taken > during stage demotion but virtually masked, as your pointed out), and we > must play them before returning to userland. > > [snip] > > > Taken from arm64/x86: > > if (unlikely(running_oob() || irqs_disabled())) { > > ... > > handle_irq_pipelined_finish(prevd, regs); > > if (running_inband() && user_mode(regs)) { > > stall_inband_nocheck(); > > irqentry_exit_to_user_mode(regs); > > } > > ... > > } > > > > > again: > > > ti_work = read_thread_flags(); > > > if (unlikely(ti_work & EXIT_TO_USER_MODE_WORK)) > > Incidentally, I just noticed that arm64 looks wrong > here. arm64_pipeline_el0_irq() lacks the demotion check in the > running_oob() case, and arm64_pipeline_el1_irq() unfortunately checks > for user_mode(regs) in arm64_pipeline_el1_irq(). I'll leave the > conclusion to the careful reader. I noticed that as well while reviewing the patch proposal from Tobias. Patch is already under CI testing... > > > > > That said, we should double check that this corner case is handled right > > on arm. If arm suffers from the same problem, this corner case is > > missing in handle_irq_pipelined(). > > > > I hope all of this makes sense at the end. It's late... > > > > Best regards, > > Florian > > > > [2. text/vcard; florian_bezdeka.vcf]... > > -- > Philippe.