Re: [Xenomai-core] [RFC] Break out of endless user space loops
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. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Break out of endless user space loops
Philippe Gerum wrote: On Wed, 2010-06-02 at 19:19 +0200, 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). This is an x86-64-only draft which clearly needs more love. I'm open for suggestions of different abstractions wherever you see a need. What if you have no MMU ? Then you either have an MPU detecting NULL pointer accesses or you can actually redirect the PC to some kernel function containing some other invalid, exception-raising instruction. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Break out of endless user space loops
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. 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. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Break out of endless user space loops
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Break out of endless user space loops
On Thu, 2010-06-03 at 12:18 +0200, Jan Kiszka wrote: 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. Try calling ipipe_get_irq_regs within a root domain IRQ handler, then, we'll resume this discussion right after - you may have another perception of the situation. You will get NULL once in a while, albeit you are running over an IRQ context, from a Linux POV. 100% reliable for a published ipipe interface means that it ought to work when called from _all_ domains, unless its semantics specifically dictates a particular context for use. By no mean ipipe_get_irq_regs tells anyone that it may only be used reliably on behalf of an unlocked, wired, directly dispatched IRQ. The only IRQ that fits this description is the pipelined hrtimer irq (not even the host one, the host one simply inherits this property when it happens that hrtimer == host timer for the underlying architecture), and the only domain which may assume this safely is the invariant head, which certainly restricts quite a bit the valid context for using those services. 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. I agree, we do need something to ALLOWS US fixup the frame for the return address to be correct. I'm just asking that we do provide a clean interface for this, since it will be there to stay. Jan -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Break out of endless user space loops
Philippe Gerum wrote: On Thu, 2010-06-03 at 12:18 +0200, Jan Kiszka wrote: 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. Try calling ipipe_get_irq_regs within a root domain IRQ handler, then, we'll resume this discussion right after - you may have another perception of the situation. You will get NULL once in a while, albeit you are running over an IRQ context, from a Linux POV. 100% reliable for a published ipipe interface means that it ought to work when called from _all_ domains, unless its semantics specifically dictates a particular context for use. By no mean ipipe_get_irq_regs tells anyone that it may only be used reliably on behalf of an unlocked, wired, directly dispatched IRQ. The only IRQ that fits this description is the pipelined hrtimer irq (not even the host one, the host one simply inherits this property when it happens that hrtimer == host timer for the underlying architecture), and the only domain which may assume this safely is the invariant head, which certainly restricts quite a bit the valid context for using those services. 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. I agree, we do need something to ALLOWS US fixup the frame for the return address to be correct. I'm just asking that we do provide a clean interface for this, since it will be there to stay. Ack. I'm already looking into some way to pimp up ipipe_get_irq_regs so that it can replace the x86 tick_regs and will never be NULL inside an IRQ handler. The only thing that is missing is filling in the proper context that unblocked some pipeline and triggers an IRQ replay this way. Should be fairly simple. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Break out of endless user space loops
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. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Break out of endless user space loops
On Wed, 2010-06-02 at 19:19 +0200, 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).
This is an x86-64-only draft which clearly needs more love. I'm open for
suggestions of different abstractions wherever you see a need.
What if you have no MMU ?
Jan
---
include/asm-generic/hal.h|2 ++
include/asm-x86/bits/thread_64.h |1 +
include/asm-x86/system_64.h | 26 ++
ksrc/nucleus/pod.c |5 +
ksrc/nucleus/sched.c |1 +
5 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/hal.h b/include/asm-generic/hal.h
index 84c1a4d..be6abf0 100644
--- a/include/asm-generic/hal.h
+++ b/include/asm-generic/hal.h
@@ -96,6 +96,8 @@ typedef spinlock_t rthal_spinlock_t;
#define rthal_irq_cookie(ipd,irq)__ipipe_irq_cookie(ipd,irq)
#define rthal_irq_handler(ipd,irq) __ipipe_irq_handler(ipd,irq)
+#define rthal_get_irq_regs() ipipe_get_irq_regs()
+
#define rthal_cpudata_irq_hits(ipd,cpu,irq)
__ipipe_cpudata_irq_hits(ipd,cpu,irq)
#ifndef local_irq_save_hw_smp
diff --git a/include/asm-x86/bits/thread_64.h
b/include/asm-x86/bits/thread_64.h
index 91b71ed..d163c9e 100644
--- a/include/asm-x86/bits/thread_64.h
+++ b/include/asm-x86/bits/thread_64.h
@@ -33,6 +33,7 @@ static inline void xnarch_init_tcb(xnarchtcb_t * tcb)
tcb-ripp = tcb-rip;
tcb-fpup = tcb-i387;
tcb-is_root = 0;
+ tcb-forced_um_exit = 0;
/* Must be followed by xnarch_init_thread(). */
}
diff --git a/include/asm-x86/system_64.h b/include/asm-x86/system_64.h
index 4de8693..f023dab 100644
--- a/include/asm-x86/system_64.h
+++ b/include/asm-x86/system_64.h
@@ -60,6 +60,8 @@ typedef struct xnarchtcb { /* Per-thread
arch-dependent block */
unsigned long ts_usedfpu: 1;
unsigned long cr0_ts: 1;
+ unsigned long forced_um_exit: 1;
+
unsigned stacksize; /* Aligned size of stack (bytes) */
unsigned long *stackbase; /* Stack space */
@@ -122,6 +124,30 @@ static inline void xnarch_free_stack_mem(void *chunk,
u_long bytes)
kfree(chunk);
}
+static inline void xnarch_force_userspace_exit(xnarchtcb_t *tcb)
+{
+ struct pt_regs *regs = rthal_get_irq_regs();
+
+ if (user_mode(regs)) {
+ tcb-rip = regs-x86reg_ip;
+ tcb-forced_um_exit = 1;
+ regs-x86reg_ip = 0;
+ }
+}
+
+static inline int
+xnarch_fixup_userspace_exit(xnarchtcb_t *tcb, xnarch_fltinfo_t *fi)
+{
+#ifdef CONFIG_XENO_OPT_PERVASIVE
+ if (tcb-forced_um_exit) {
+ fi-regs-x86reg_ip = tcb-rip;
+ tcb-forced_um_exit = 0;
+ return 1;
+ }
+#endif /* CONFIG_XENO_OPT_PERVASIVE */
+ return 0;
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
index 7002a73..bdb5758 100644
--- a/ksrc/nucleus/pod.c
+++ b/ksrc/nucleus/pod.c
@@ -2547,6 +2547,11 @@ int xnpod_trap_fault(xnarch_fltinfo_t *fltinfo)
thread = xnpod_current_thread();
+ if (xnarch_fixup_userspace_exit(xnthread_archtcb(thread), fltinfo)) {
+ xnshadow_relax(0, 0);
+ return 1;
+ }
+
trace_mark(xn_nucleus, thread_fault,
thread %p thread_name %s ip %p type %d,
thread, xnthread_name(thread),
diff --git a/ksrc/nucleus/sched.c b/ksrc/nucleus/sched.c
index 0b737a3..64fa0e0 100644
--- a/ksrc/nucleus/sched.c
+++ b/ksrc/nucleus/sched.c
@@ -100,6 +100,7 @@ static void xnsched_watchdog_handler(struct xntimer
*timer)
'%s'\n, xnthread_name(thread));
xnthread_set_info(thread, XNAMOK | XNKICKED);
xnshadow_send_sig(thread, SIGDEBUG, SIGDEBUG_WATCHDOG, 1);
+ xnarch_force_userspace_exit(xnthread_archtcb(thread));
} else
#endif /* CONFIG_XENO_OPT_PERVASIVE */
{
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
