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

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2574 bytes --]

Philippe Gerum wrote:
> 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.

There is no use for ipipe_get_irq_regs in our case outside the call
stack of the triggering IRQ. If you have nested IRQs inside this stack,
ipipe_get_irq_regs account for this, if you leave the stack, it returns
NULL. This is 100% reliable.

If you want read-only access to the preempted register set, then we need
some other mechanism, something like the tick regs. But those already
exits, and we have no other users beyond the host tick so far.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]