Re: [Xenomai-core] [Xenomai-git] Jan Kiszka : nucleus: Fix race between gatekeeper and thread deletion

[Philippe Gerum <rpm@xenomai.org>]

On Sat, 2011-07-16 at 10:13 +0200, Jan Kiszka wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2011-07-15 15:10, Jan Kiszka wrote:
> > But... right now it looks like we found our primary regression: 
> > "nucleus/shadow: shorten the uninterruptible path to secondary mode".
> > It opens a short windows during relax where the migrated task may be
> > active under both schedulers. We are currently evaluating a revert
> > (looks good so far), and I need to work out my theory in more
> > details.
> 
> Looks like this commit just made a long-standing flaw in Xenomai's
> interrupt handling more visible: We reschedule over the interrupt stack
> in the Xenomai interrupt handler tails, at least on x86-64. Not sure if
> other archs have interrupt stacks, the point is Xenomai's design wrongly
> assumes there are no such things.

Fortunately, no, this is not a design issue, no such assumption was ever
made, but the Xenomai core expects this to be handled on a per-arch
basis with the interrupt pipeline. As you pointed out, there is no way
to handle this via some generic Xenomai-only support.

ppc64 now has separate interrupt stacks, which is why I disabled
IRQSTACKS which became the builtin default at some point. Blackfin goes
through a Xenomai-defined irq tail handler as well, because it may not
reschedule over nested interrupt stacks. Fact is that such pending
problem with x86_64 was overlooked since day #1 by /me.

>  We were lucky so far that the values
> saved on this shared stack were apparently "compatible", means we were
> overwriting them with identical or harmless values. But that's no longer
> true when interrupts are hitting us in the xnpod_suspend_thread path of
> a relaxing shadow.
> 

Makes sense. It would be better to find a solution that does not make
the relax path uninterruptible again for a significant amount of time.
On low end platforms we support (i.e. non-x86* mainly), this causes
obvious latency spots.

> Likely the only possible fix is establishing a reschedule hook for
> Xenomai in the interrupt exit path after the original stack is restored
> - - just like Linux works. Requires changes to both ipipe and Xenomai
> unfortunately.

__ipipe_run_irqtail() is in the I-pipe core for such purpose. If
instantiated properly for x86_64, and paired with xnarch_escalate() for
that arch as well, it could be an option for running the rescheduling
procedure when safe.

> 
> Jan
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk4hSDsACgkQitSsb3rl5xSmOACfbZfcNKyO9YDvPE+R5H75d0ky
> DX0An32BrZW+lpEnxnLLCHSQ5r8itnE9
> =n6u8
> -----END PGP SIGNATURE-----

-- 
Philippe.