Re: [Xenomai-core] [RFC] Break out of endless user space loops

[Philippe Gerum <rpm@xenomai.org>]

On Thu, 2010-06-03 at 10:47 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Thu, 2010-06-03 at 08:55 +0200, Jan Kiszka wrote:
> >> Gilles Chanteperdrix wrote:
> >>> Jan Kiszka wrote:
> >>>> Hi all,
> >>>>
> >>>> here is the first apparently working prototype for getting hold of
> >>>> endless user space loops in RT threads. A simple test case of mine now
> >>>> receive a SIGDEBUG even if it does "while (1);".
> >>>>
> >>>> The design follows Gilles' suggestion to force a SEGV on victim thread
> >>>> but restore the patched PC before migrating the thread after this fault.
> >>>> The only drawback of this approach: We need to keep track of the
> >>>> preempted register set at I-pipe level. I basically replicated what
> >>>> Linux does these days as well and exported it as ipipe_get_irq_regs()
> >>>> (the second patch).
> >>> You already have the regs in xnarch_fault_info.
> >>>
> >> We only pass this around for exceptions.
> > 
> > And for a good reason, exceptions are always delivered synchronously
> > upon receipt, not IRQs, given the deferred dispatching scheme. Your
> > ipipe_get_irq_regs interface is inherently broken for anything which is
> > not a wired-mode timer IRQ, since you could pass the caller a reference
> > to an unwound stack frame.
> 
> It may not work for certain deferred IRQs, true, but then it will return
> NULL. The user of ipipe_get_irq_regs has to take this into account. And
> most consumers will be wired IRQ handler anyway.
> 
> > 
> > You have to resort to __ipipe_tick_regs, and obviously only use this in
> > the context of a timer-triggered code, like the watchdog handler, which
> > saves your day.
> 
> Doesn't work if the timer IRQ is not the host tick AND doesn't help us
> modifying the return path.

That is not the basic issue, copying back regs->ip to the actual frame
before yielding to the IRQ trampoline code would be trivial and your
patch does require a deeper change in the ipipe already. The issue is:
do not provide a service which is not 100% trustable in this area.

> Granted, the former scenario is already broken in I-pipe (try using an
> x86 host with an MSI-capable HPET...), but the latter is definitely a no-go.
> 

I'm arguing that your ipipe_get_irq_regs interface is broken by design
pipeline-wise; piling up more crap in the pipeline core that is wrong
already for some x86 timer sources won't help. The point is: you have to
explicitly address that case only considering the timer interrupt, in
wired-mode, because this won't fly in any other cases.

> Jan
> 


-- 
Philippe.