From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5586FA30.8020302@web.de> Date: Sun, 21 Jun 2015 19:53:52 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <558579E2.9070507@web.de> <5585ADDE.9070005@xenomai.org> In-Reply-To: <5585ADDE.9070005@xenomai.org> Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Subject: Re: [Xenomai] Mayday issues again List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: Xenomai On 2015-06-20 20:15, Philippe Gerum wrote: > On 06/20/2015 04:34 PM, Jan Kiszka wrote: >> Hi Philippe, >> >> the mayday mechanism is causing troubles to me again. >> >> First of all, there is a bug /wrt restarting the mayday syscall. We >> current don't restart on pending signals, thus destroy the register of >> the interrupted thread that contains the syscall return code. See my >> for-forge branch for a fix proposal. >> >> But actually I would like to get rid of the syscall trampoline >> completely if somehow possible, at least for certain archs. The reason >> is that it ruins debuggability. If a RT thread is stopped by gdb with >> the help of the mayday mechanism, it ends up waiting for resumption on >> the mayday page. Even worse, backtracing is broken, at least on x86. >> >> That brings me to the key question: why do we need the syscall >> trampoline? We set TIP_MAYDAY in the target task, the task causes >> IPIPE_TRAP_MAYDAY to be reported via the trap hook, the hook sets the >> trampoline code, the trampoline triggers the syscall, and only on >> syscall return, we finally migrate the task to Linux. What prevents >> doing the migration already in the trap hook, ie. in >> handle_mayday_event? The pattern seems similar to the migration we >> trigger on userspace faults. And it seems to works, at least for x86, >> and doesn't have the unwanted side effects. >> >> The background of this work is improving gdb support, in particular >> deterministic stopping and resuming of multi-threaded RT processes. I'm >> still in the design & prototype phase, RFC patches will follow later. >> > = > Ok. The proposed design has to cover the basic case solved by the mayday > mechanism, i.e. a runaway thread spinning into a syscall-less loop. > = > e.g. it should be able to switch such code back to secondary mode: > = > for (;;) ; > = Related smokey test case passes, both on x86 and ARM. Other archs need to be checked carefully, though. I've pushed a commit that radically removes everything, but essentially does this: diff --git a/kernel/cobalt/posix/process.c b/kernel/cobalt/posix/process.c index 6110da6..85e9144 100644 --- a/kernel/cobalt/posix/process.c +++ b/kernel/cobalt/posix/process.c @@ -762,16 +761,9 @@ static inline int handle_exception(struct ipipe_trap_d= ata *d) = static int handle_mayday_event(struct pt_regs *regs) { - struct xnthread *thread =3D xnthread_current(); - struct xnarchtcb *tcb =3D xnthread_archtcb(thread); - struct cobalt_ppd *sys_ppd; - - XENO_BUG_ON(COBALT, !xnthread_test_state(thread, XNUSER)); + XENO_BUG_ON(COBALT, !xnthread_test_state(xnthread_current(), XNUSER)); = - /* We enter the mayday handler with hw IRQs off. */ - sys_ppd =3D cobalt_ppd_get(0); - - xnarch_handle_mayday(tcb, regs, sys_ppd->mayday_tramp); + xnthread_relax(0, 0); = return KEVENT_PROPAGATE; } Could you check this on the other archs? Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: