Re: [Xenomai] Mayday issues again

[Jan Kiszka <jan.kiszka@web.de>]

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_data *d)
 
 static int handle_mayday_event(struct pt_regs *regs)
 {
-	struct xnthread *thread = xnthread_current();
-	struct xnarchtcb *tcb = 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 = 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: <http://xenomai.org/pipermail/xenomai/attachments/20150621/dbcc3853/attachment.sig>