Re: [PATCH dovetail] irq_pipeline: synchronize inband IRQ log in exit_to_user_mode_prepare()

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.

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