Re: [Xenomai-core] Antwort: Re: Antwort: Re: Arguments in psos t_start()
On Wed, 2007-05-09 at 11:57 +0200, Markus Osterried wrote: > Hello Gerum, > > actually, when the task's user function (the function which is given in > t_start()) is entered, the arguments have been copied to the new context > and are passed by value. > This is true for real pSOS and also for Xenomai. > But in Xenomai it's the trampoline which acts as a wrapper/prolog and is > created and ready to run in a concurrent context, while still holding a > reference to the arguments in the creator's context. > Real pSOS is a blackbox, so I don't no whether there is a moment in time, > where a new concurrent context is running while still holding a pointer to > old context. To explain how the pSOS skin currently works: starter task: == syscall == t_start(targs[] by reference) kernel/skin: receives the genuine "targ" _pointer_, and copies it unmodified to the new task's trampoline code in user-space + wakes up the new task so that it really starts execution (i.e. it was locked into the trampoline code). new task (in trampoline code): ==syscall== wait on the start barrier kernel/skin: makes caller wait until t_start is issued receives "targs" pointer verbatim, copied back by the last syscall, and dereferences it to pass the 4 long words from the targs array to the callback entry routine of the new task. So, the issue that could happen, is the caller of the t_start() function in user-space returning to its own caller, with "targs" being laid into the stack space being unwound. _That_ would be a rainy day. The only issue otherwise, is the caller of t_start() modifying the arguments before or while the resumed task accesses them, but that would be more of a reasonable side-effect of passing arguments by reference, that a bug per se. Except of course, if pSOS does differently, and always copies the argument array in the t_start() syscall. > But it's the fact, we have sometimes seen problems with Xenomai, when our > pSOS application changes the arguments value after t_start(). > We have never seen this in pSOS. > It's worth to mention, I haven't seen this problem with the newest Xenomai > branch (there was some changes in scheduling?). > But I'm not sure the problem is 100% solved, because with older Xenomai we > have sometimes seen the problem and sometimes not. :-( Please be specific; which are the "older Xenomai" and "newest Xenomai branch"? i.e. which stable version number or SVN commit number for the trunk/? This said, I definitely fixed a scheduling issue due to primary/secondary mode switches involved in creating new user-space tasks which has been committed in v2.3.1 (i.e. a major rework of the so-called "RPI management", after Thomas sent me a test case to illustrate the issue). This bug, for sure, could have impacted your application in the situation I described earlier, regarding t_start arguments laid into the stack space. But I have not enough details to be 100% this was related to your problem though. > > > Markus > > > > > > > > Philippe Gerum > > <[EMAIL PROTECTED] An: Markus > Osterried <[EMAIL PROTECTED]> > g> Kopie: > xenomai-core@gna.org > > Gesendet von: Blindkopie: > > xenomai-core-bo Thema: Re: > [Xenomai-core] Antwort: Re: Arguments in psos t_start() > [EMAIL PROTECTED] > > > > > > 09.05.2007 > > 09:55 > > Bitte antworten > > an rpm >
[Xenomai-core] Antwort: Re: Antwort: Re: Arguments in psos t_start()
Hello Gerum, actually, when the task's user function (the function which is given in t_start()) is entered, the arguments have been copied to the new context and are passed by value. This is true for real pSOS and also for Xenomai. But in Xenomai it's the trampoline which acts as a wrapper/prolog and is created and ready to run in a concurrent context, while still holding a reference to the arguments in the creator's context. Real pSOS is a blackbox, so I don't no whether there is a moment in time, where a new concurrent context is running while still holding a pointer to old context. But it's the fact, we have sometimes seen problems with Xenomai, when our pSOS application changes the arguments value after t_start(). We have never seen this in pSOS. It's worth to mention, I haven't seen this problem with the newest Xenomai branch (there was some changes in scheduling?). But I'm not sure the problem is 100% solved, because with older Xenomai we have sometimes seen the problem and sometimes not. :-( Markus Philippe Gerum <[EMAIL PROTECTED] An: Markus Osterried <[EMAIL PROTECTED]> g> Kopie: xenomai-core@gna.org Gesendet von: Blindkopie: xenomai-core-bo Thema: Re: [Xenomai-core] Antwort: Re: Arguments in psos t_start() [EMAIL PROTECTED] 09.05.2007 09:55 Bitte antworten an rpm On Wed, 2007-05-09 at 09:07 +0200, Markus Osterried wrote: > Hello Gerum, > > sorry for not knowing the details. But there is another question. > Is it okay to move the pointer to the arguments to the newly created task? > Isn't it possible that the task which created the new task is rescheduled? > The old task could change the value of the argument and because the new > task only holds a reference to this argument, the new task is also > affected. > Yes, such side-effect would be possible, not necessarily for the creator, but for the thread calling t_start() though. The worst case would happen when calling t_start() with args laid into the caller's stack space, and the caller unwinding the current frame immediately since it has a higher priority than the started thread. This boils down to one question: does actually pSOS pass the argument array by reference, or by value? In the latter case, the current implementation would be wrong, otherwise, the side-effect would be admitted. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Antwort: Re: Arguments in psos t_start()
On Wed, 2007-05-09 at 09:07 +0200, Markus Osterried wrote: > Hello Gerum, > > sorry for not knowing the details. But there is another question. > Is it okay to move the pointer to the arguments to the newly created task? > Isn't it possible that the task which created the new task is rescheduled? > The old task could change the value of the argument and because the new > task only holds a reference to this argument, the new task is also > affected. > Yes, such side-effect would be possible, not necessarily for the creator, but for the thread calling t_start() though. The worst case would happen when calling t_start() with args laid into the caller's stack space, and the caller unwinding the current frame immediately since it has a higher priority than the started thread. This boils down to one question: does actually pSOS pass the argument array by reference, or by value? In the latter case, the current implementation would be wrong, otherwise, the side-effect would be admitted. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Antwort: Re: Arguments in psos t_start()
Hello Gerum,
sorry for not knowing the details. But there is another question.
Is it okay to move the pointer to the arguments to the newly created task?
Isn't it possible that the task which created the new task is rescheduled?
The old task could change the value of the argument and because the new
task only holds a reference to this argument, the new task is also
affected.
Thank you
Markus
Philippe Gerum
<[EMAIL PROTECTED] An: Markus
Osterried <[EMAIL PROTECTED]>
g> Kopie:
xenomai-core@gna.org
Gesendet von: Blindkopie:
xenomai-core-bo Thema: Re:
[Xenomai-core] Arguments in psos t_start()
[EMAIL PROTECTED]
08.05.2007
16:55
Bitte antworten
an rpm
On Tue, 2007-05-08 at 16:07 +0200, Markus Osterried wrote:
> Hello Phillipe,
>
> in __t_start() in /ksrc/skins/psos+/syscall.c the pointer to the
> (user-space) tasks argument is directly used for the (kernel-space)
> t_start() call.
>
> u_long *argp;
> argp = (u_long *)__xn_reg_arg4(regs);
> return t_start((u_long)task, mode, startaddr, argp);
>
>
> I think the arguments must be copied to kernel-space, so isn't it better
to
> do it this way?
>
> u_long arg[4];
> if (!__xn_access_ok
> (curr, VERIFY_READ, __xn_reg_arg4(regs), sizeof(u_long[4])))
> return -EFAULT;
> __xn_copy_from_user(curr, arg, (void __user *)__xn_reg_arg4(regs),
>sizeof(u_long[4]));
> return t_start((u_long)task, mode, startaddr, arg);
>
Actually, we currently don't need to know anything about the task args
from kernel space, since we only have to relay their address to the task
trampoline code in src/skins/psos/task.c. However, we must not try to
access those args from kernel space. The patch below fixes this bug.
Thanks for pointing this out.
--- ksrc/skins/psos+/task.c (revision 2395)
+++ ksrc/skins/psos+/task.c (working copy)
@@ -197,9 +197,6 @@
xnmode = psos_mode_to_xeno(mode);
-for (n = 0; n < 4; n++)
-task->args[n] = targs ? targs[n] : 0;
-
task->entry = startaddr;
#if defined(__KERNEL__) && defined(CONFIG_XENO_OPT_PERVASIVE)
@@ -214,10 +211,15 @@
XNPOD_ALL_CPUS, (void
(*)(void *))startaddr, targs);
else
#endif /* __KERNEL__ && CONFIG_XENO_OPT_PERVASIVE */
+{
+for (n = 0; n < 4; n++)
+task->args[n] = targs ? targs[n] : 0;
+
xnpod_start_thread(&task->threadbase,
xnmode,
(int)((mode >> 8) &
0x7),
XNPOD_ALL_CPUS,
&psostask_trampoline, task);
+}
unlock_and_exit:
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
