Am 15.11.2010 20:31, Jan Kiszka wrote: > Hi Philippe, > > debugging some variant of I-pipe over an x86-32 target, I think I found > some fairly old flaw in the IRQ virtualization that causes rescheduling > delays (up to deadlocks) for Linux: > > - we are in sysenter_tail (other exit paths should be affected as well) > - we DISABLE_INTERRUPTS, but only virtually > - we go past "testl $_TIF_ALLWORK_MASK, %ecx", nothing to be done > - an IRQ for Linux arrives, it is pushed to the backlog > - __ipipe_unstall_iret_root replays the IRQ as the regs we are about to > return to have IF set (obviously, we return from a syscall) > - the Linux IRQ handler sets _TIF_NEED_RESCHED, but doesn't perform the > work on return as __ipipe_sync_stage set the stall flag for the Linux > domain before calling the handler > - but now the preempted sysenter return also does no reschedule as it > already passed the check - bang! > > Another variant of this Linux rescheduling issue: > > - we are in a lengthy loop inside the kernel, but we are preemptible > most of the time > - after disabling Linux IRQs briefly, we are calling > local_irq_enable() again > - in the meantime, we received a Linux IRQ which is now pending in the > backlog > - __ipipe_unstall_root triggers __ipipe_sync_stage > - Linux handler is called, sets NEED_RESCHED but does not reschedule > (see above) > - we do not test for resched again as we are not returning to user > space, and that for quite some time - bang!
And this one actually affects x86-64 as well: Here, ret_from_intr checks for NEED_RESCHED only if IF is set in the flags of the preempted context. But if the Linux domain is alone, we enter __ipipe_do_root_xirq with hard IRQs disabled, thus we push this information incorrectly on the Linux handler stack, preventing the required rescheduling check. I guess the simplest fix for this is to drop the "!__ipipe_pipeline_head_p(ipd)" check from __ipipe_sync_stage. > > I think both issues are only related to virtualizing DISABLE_INTERRUPTS > for entry_32.S and I wonder if this doesn't finally qualify for a switch > to the 64-bit model. Or do you see simpler fixes? > Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
