* [Xenomai-help] Suspended task resumed without rt_task_resume ?
@ 2008-04-14 3:53 Tomas Kalibera
2008-04-14 8:21 ` Philippe Gerum
0 siblings, 1 reply; 7+ messages in thread
From: Tomas Kalibera @ 2008-04-14 3:53 UTC (permalink / raw
To: xenomai
Hi,
what can, besides an explicit call, resume a suspended task ? I created
and started a child task, then shadowed the current thread with T_SUSP
flag. The child was supposed to call rt_task_resume to wake-up the
parent and let it terminate the process, but, the parent was resumed
before this call. The call to rt_task_suspend in parent returned 0. The
program uses SIGALRM signal. Could this be the cause ?
Thanks,
Tomas
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] Suspended task resumed without rt_task_resume ?
2008-04-14 3:53 [Xenomai-help] Suspended task resumed without rt_task_resume ? Tomas Kalibera
@ 2008-04-14 8:21 ` Philippe Gerum
2008-04-14 8:26 ` Philippe Gerum
0 siblings, 1 reply; 7+ messages in thread
From: Philippe Gerum @ 2008-04-14 8:21 UTC (permalink / raw
To: Tomas Kalibera; +Cc: xenomai
Tomas Kalibera wrote:
> Hi,
>
> what can, besides an explicit call, resume a suspended task ? I created
> and started a child task, then shadowed the current thread with T_SUSP
> flag. The child was supposed to call rt_task_resume to wake-up the
> parent and let it terminate the process, but, the parent was resumed
> before this call. The call to rt_task_suspend in parent returned 0. The
> program uses SIGALRM signal. Could this be the cause ?
>
Yes, but the syscall should be silently restarted by default. This patch should
fix the issue:
--- ksrc/skins/native/task.c (revision 3698)
+++ ksrc/skins/native/task.c (working copy)
@@ -410,11 +410,17 @@
* A nesting count is maintained so that rt_task_suspend() and
* rt_task_resume() must be used in pairs.
*
+ * Receiving a Linux signal causes the suspended task to resume
+ * immediately.
+ *
* @param task The descriptor address of the affected task. If @a task
* is NULL, the current task is suspended.
*
* @return 0 is returned upon success. Otherwise:
*
+ * - -EINTR is returned if a Linux signal has been received by the
+ * suspended task.
+ *
* - -EINVAL is returned if @a task is not a task descriptor.
*
* - -EPERM is returned if the addressed @a task is not allowed to sleep
@@ -463,9 +469,12 @@
goto unlock_and_exit;
}
- if (task->suspend_depth++ == 0)
+ if (task->suspend_depth++ == 0) {
xnpod_suspend_thread(&task->thread_base, XNSUSP,
XN_INFINITE, XN_RELATIVE, NULL);
+ if (xnthread_test_info(task, XNBREAK))
+ err = -EINTR;
+ }
unlock_and_exit:
--
Philippe.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] Suspended task resumed without rt_task_resume ?
2008-04-14 8:21 ` Philippe Gerum
@ 2008-04-14 8:26 ` Philippe Gerum
2008-04-14 20:01 ` Tomas Kalibera
0 siblings, 1 reply; 7+ messages in thread
From: Philippe Gerum @ 2008-04-14 8:26 UTC (permalink / raw
To: Tomas Kalibera; +Cc: xenomai
Philippe Gerum wrote:
> Tomas Kalibera wrote:
>> Hi,
>>
>> what can, besides an explicit call, resume a suspended task ? I created
>> and started a child task, then shadowed the current thread with T_SUSP
>> flag. The child was supposed to call rt_task_resume to wake-up the
>> parent and let it terminate the process, but, the parent was resumed
>> before this call. The call to rt_task_suspend in parent returned 0. The
>> program uses SIGALRM signal. Could this be the cause ?
>>
>
> Yes, but the syscall should be silently restarted by default. This patch should
> fix the issue:
>
This one will compile:
--- ksrc/skins/native/task.c (revision 3698)
+++ ksrc/skins/native/task.c (working copy)
@@ -410,11 +410,17 @@
* A nesting count is maintained so that rt_task_suspend() and
* rt_task_resume() must be used in pairs.
*
+ * Receiving a Linux signal causes the suspended task to resume
+ * immediately.
+ *
* @param task The descriptor address of the affected task. If @a task
* is NULL, the current task is suspended.
*
* @return 0 is returned upon success. Otherwise:
*
+ * - -EINTR is returned if a Linux signal has been received by the
+ * suspended task.
+ *
* - -EINVAL is returned if @a task is not a task descriptor.
*
* - -EPERM is returned if the addressed @a task is not allowed to sleep
@@ -463,9 +469,12 @@
goto unlock_and_exit;
}
- if (task->suspend_depth++ == 0)
+ if (task->suspend_depth++ == 0) {
xnpod_suspend_thread(&task->thread_base, XNSUSP,
XN_INFINITE, XN_RELATIVE, NULL);
+ if (xnthread_test_info(&task->thread_base, XNBREAK))
+ err = -EINTR;
+ }
unlock_and_exit:
--
Philippe.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] Suspended task resumed without rt_task_resume ?
2008-04-14 8:26 ` Philippe Gerum
@ 2008-04-14 20:01 ` Tomas Kalibera
2008-04-14 20:32 ` Philippe Gerum
0 siblings, 1 reply; 7+ messages in thread
From: Tomas Kalibera @ 2008-04-14 20:01 UTC (permalink / raw
To: rpm; +Cc: xenomai
Hi Philippe,
does your patch fix also the situation when the task is suspended via
T_SUSP flag from rt_task_shadow (and calls which start tasks, for that
matter) ?
Then I've applied your patch to task.c in my kernel tree, recompiled the
kernel, and my task is still getting resumed too early, returning 0.
Even when I use rt_task_suspend. Could this be caused by something else ?
Thanks,
Tomas
Philippe Gerum wrote:
> Philippe Gerum wrote:
>
>> Tomas Kalibera wrote:
>>
>>> Hi,
>>>
>>> what can, besides an explicit call, resume a suspended task ? I created
>>> and started a child task, then shadowed the current thread with T_SUSP
>>> flag. The child was supposed to call rt_task_resume to wake-up the
>>> parent and let it terminate the process, but, the parent was resumed
>>> before this call. The call to rt_task_suspend in parent returned 0. The
>>> program uses SIGALRM signal. Could this be the cause ?
>>>
>>>
>> Yes, but the syscall should be silently restarted by default. This patch should
>> fix the issue:
>>
>>
>
> This one will compile:
>
> --- ksrc/skins/native/task.c (revision 3698)
> +++ ksrc/skins/native/task.c (working copy)
> @@ -410,11 +410,17 @@
> * A nesting count is maintained so that rt_task_suspend() and
> * rt_task_resume() must be used in pairs.
> *
> + * Receiving a Linux signal causes the suspended task to resume
> + * immediately.
> + *
> * @param task The descriptor address of the affected task. If @a task
> * is NULL, the current task is suspended.
> *
> * @return 0 is returned upon success. Otherwise:
> *
> + * - -EINTR is returned if a Linux signal has been received by the
> + * suspended task.
> + *
> * - -EINVAL is returned if @a task is not a task descriptor.
> *
> * - -EPERM is returned if the addressed @a task is not allowed to sleep
> @@ -463,9 +469,12 @@
> goto unlock_and_exit;
> }
>
> - if (task->suspend_depth++ == 0)
> + if (task->suspend_depth++ == 0) {
> xnpod_suspend_thread(&task->thread_base, XNSUSP,
> XN_INFINITE, XN_RELATIVE, NULL);
> + if (xnthread_test_info(&task->thread_base, XNBREAK))
> + err = -EINTR;
> + }
>
> unlock_and_exit:
>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] Suspended task resumed without rt_task_resume ?
2008-04-14 20:01 ` Tomas Kalibera
@ 2008-04-14 20:32 ` Philippe Gerum
2008-04-14 20:50 ` Tomas Kalibera
0 siblings, 1 reply; 7+ messages in thread
From: Philippe Gerum @ 2008-04-14 20:32 UTC (permalink / raw
To: Tomas Kalibera; +Cc: xenomai
Tomas Kalibera wrote:
>
> Hi Philippe,
>
> does your patch fix also the situation when the task is suspended via
> T_SUSP flag from rt_task_shadow (and calls which start tasks, for that
> matter) ?
>
No, that is a different case; this patches only ensures that rt_task_suspend()
shall be automatically restarted upon signal receipt when called for the running
task.
> Then I've applied your patch to task.c in my kernel tree, recompiled the
> kernel, and my task is still getting resumed too early, returning 0.
> Even when I use rt_task_suspend. Could this be caused by something else ?
>
No, it does happen due to the shadowed task receiving SIGALRM. If you don't want
this to happen, just block the signals before calling rt_task_shadow(). There is
no other way, we may not restart the shadow mapping request upon signal receipt
anyway.
> Thanks,
> Tomas
>
>
>
> Philippe Gerum wrote:
>> Philippe Gerum wrote:
>>
>>> Tomas Kalibera wrote:
>>>
>>>> Hi,
>>>>
>>>> what can, besides an explicit call, resume a suspended task ? I
>>>> created and started a child task, then shadowed the current thread
>>>> with T_SUSP flag. The child was supposed to call rt_task_resume to
>>>> wake-up the parent and let it terminate the process, but, the parent
>>>> was resumed before this call. The call to rt_task_suspend in parent
>>>> returned 0. The program uses SIGALRM signal. Could this be the cause ?
>>>>
>>>>
>>> Yes, but the syscall should be silently restarted by default. This
>>> patch should
>>> fix the issue:
>>>
>>>
>>
>> This one will compile:
>>
>> --- ksrc/skins/native/task.c (revision 3698)
>> +++ ksrc/skins/native/task.c (working copy)
>> @@ -410,11 +410,17 @@
>> * A nesting count is maintained so that rt_task_suspend() and
>> * rt_task_resume() must be used in pairs.
>> *
>> + * Receiving a Linux signal causes the suspended task to resume
>> + * immediately.
>> + *
>> * @param task The descriptor address of the affected task. If @a task
>> * is NULL, the current task is suspended.
>> *
>> * @return 0 is returned upon success. Otherwise:
>> *
>> + * - -EINTR is returned if a Linux signal has been received by the
>> + * suspended task.
>> + *
>> * - -EINVAL is returned if @a task is not a task descriptor.
>> *
>> * - -EPERM is returned if the addressed @a task is not allowed to sleep
>> @@ -463,9 +469,12 @@
>> goto unlock_and_exit;
>> }
>>
>> - if (task->suspend_depth++ == 0)
>> + if (task->suspend_depth++ == 0) {
>> xnpod_suspend_thread(&task->thread_base, XNSUSP,
>> XN_INFINITE, XN_RELATIVE, NULL);
>> + if (xnthread_test_info(&task->thread_base, XNBREAK))
>> + err = -EINTR;
>> + }
>>
>> unlock_and_exit:
>>
>>
>>
>
>
--
Philippe.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] Suspended task resumed without rt_task_resume ?
2008-04-14 20:32 ` Philippe Gerum
@ 2008-04-14 20:50 ` Tomas Kalibera
2008-04-15 7:20 ` Philippe Gerum
0 siblings, 1 reply; 7+ messages in thread
From: Tomas Kalibera @ 2008-04-14 20:50 UTC (permalink / raw
To: rpm; +Cc: xenomai
Philippe Gerum wrote:
>> does your patch fix also the situation when the task is suspended via
>> T_SUSP flag from rt_task_shadow (and calls which start tasks, for that
>> matter) ?
>>
>
> No, that is a different case; this patches only ensures that rt_task_suspend()
> shall be automatically restarted upon signal receipt when called for the running
> task.
>
I thought that the user space call to rt_task_suspend should return
-EINTR. So where is the automatic restarting ?
>> Then I've applied your patch to task.c in my kernel tree, recompiled the
>> kernel, and my task is still getting resumed too early, returning 0.
>> Even when I use rt_task_suspend. Could this be caused by something else ?
>>
>
> No, it does happen due to the shadowed task receiving SIGALRM. If you don't want
> this to happen, just block the signals before calling rt_task_shadow(). There is
> no other way, we may not restart the shadow mapping request upon signal receipt
> anyway.
>
OK, lets forget about rt_task_shadow, I agree the repetition/EINTR
semantics would be non-intuitive there. But even rt_task_suspend is
interrupted by signal, returning 0, even after applying the patch. I
don't quite understand why.
Tomas
>
>> Thanks,
>> Tomas
>>
>>
>>
>> Philippe Gerum wrote:
>>
>>> Philippe Gerum wrote:
>>>
>>>
>>>> Tomas Kalibera wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> what can, besides an explicit call, resume a suspended task ? I
>>>>> created and started a child task, then shadowed the current thread
>>>>> with T_SUSP flag. The child was supposed to call rt_task_resume to
>>>>> wake-up the parent and let it terminate the process, but, the parent
>>>>> was resumed before this call. The call to rt_task_suspend in parent
>>>>> returned 0. The program uses SIGALRM signal. Could this be the cause ?
>>>>>
>>>>>
>>>>>
>>>> Yes, but the syscall should be silently restarted by default. This
>>>> patch should
>>>> fix the issue:
>>>>
>>>>
>>>>
>>> This one will compile:
>>>
>>> --- ksrc/skins/native/task.c (revision 3698)
>>> +++ ksrc/skins/native/task.c (working copy)
>>> @@ -410,11 +410,17 @@
>>> * A nesting count is maintained so that rt_task_suspend() and
>>> * rt_task_resume() must be used in pairs.
>>> *
>>> + * Receiving a Linux signal causes the suspended task to resume
>>> + * immediately.
>>> + *
>>> * @param task The descriptor address of the affected task. If @a task
>>> * is NULL, the current task is suspended.
>>> *
>>> * @return 0 is returned upon success. Otherwise:
>>> *
>>> + * - -EINTR is returned if a Linux signal has been received by the
>>> + * suspended task.
>>> + *
>>> * - -EINVAL is returned if @a task is not a task descriptor.
>>> *
>>> * - -EPERM is returned if the addressed @a task is not allowed to sleep
>>> @@ -463,9 +469,12 @@
>>> goto unlock_and_exit;
>>> }
>>>
>>> - if (task->suspend_depth++ == 0)
>>> + if (task->suspend_depth++ == 0) {
>>> xnpod_suspend_thread(&task->thread_base, XNSUSP,
>>> XN_INFINITE, XN_RELATIVE, NULL);
>>> + if (xnthread_test_info(&task->thread_base, XNBREAK))
>>> + err = -EINTR;
>>> + }
>>>
>>> unlock_and_exit:
>>>
>>>
>>>
>>>
>>
>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] Suspended task resumed without rt_task_resume ?
2008-04-14 20:50 ` Tomas Kalibera
@ 2008-04-15 7:20 ` Philippe Gerum
0 siblings, 0 replies; 7+ messages in thread
From: Philippe Gerum @ 2008-04-15 7:20 UTC (permalink / raw
To: Tomas Kalibera; +Cc: xenomai
Tomas Kalibera wrote:
>
> Philippe Gerum wrote:
>>> does your patch fix also the situation when the task is suspended via
>>> T_SUSP flag from rt_task_shadow (and calls which start tasks, for that
>>> matter) ?
>>>
>>
>> No, that is a different case; this patches only ensures that
>> rt_task_suspend()
>> shall be automatically restarted upon signal receipt when called for
>> the running
>> task.
>>
> I thought that the user space call to rt_task_suspend should return
> -EINTR. So where is the automatic restarting ?
You will not get -EINTR, but zero, that's the intended effect of returning
-EINTR from the skin service. This will cause -ERESTARTSYS to be sent back to
the kernel, in order to handle pending signals on the Linux side. The syscall we
be restarted transparently, and rt_task_suspend() will return normally. That's
the purpose of restarting syscalls, you don't get to know that something
happened while waiting.
>>> Then I've applied your patch to task.c in my kernel tree, recompiled the
>>> kernel, and my task is still getting resumed too early, returning 0.
>>> Even when I use rt_task_suspend. Could this be caused by something
>>> else ?
>>>
>>
>> No, it does happen due to the shadowed task receiving SIGALRM. If you
>> don't want
>> this to happen, just block the signals before calling
>> rt_task_shadow(). There is
>> no other way, we may not restart the shadow mapping request upon
>> signal receipt
>> anyway.
>>
> OK, lets forget about rt_task_shadow, I agree the repetition/EINTR
> semantics would be non-intuitive there. But even rt_task_suspend is
> interrupted by signal, returning 0, even after applying the patch. I
> don't quite understand why.
>
> Tomas
>>
>>> Thanks,
>>> Tomas
>>>
>>>
>>>
>>> Philippe Gerum wrote:
>>>
>>>> Philippe Gerum wrote:
>>>>
>>>>
>>>>> Tomas Kalibera wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> what can, besides an explicit call, resume a suspended task ? I
>>>>>> created and started a child task, then shadowed the current thread
>>>>>> with T_SUSP flag. The child was supposed to call rt_task_resume to
>>>>>> wake-up the parent and let it terminate the process, but, the parent
>>>>>> was resumed before this call. The call to rt_task_suspend in parent
>>>>>> returned 0. The program uses SIGALRM signal. Could this be the
>>>>>> cause ?
>>>>>>
>>>>>>
>>>>> Yes, but the syscall should be silently restarted by default. This
>>>>> patch should
>>>>> fix the issue:
>>>>>
>>>>>
>>>> This one will compile:
>>>>
>>>> --- ksrc/skins/native/task.c (revision 3698)
>>>> +++ ksrc/skins/native/task.c (working copy)
>>>> @@ -410,11 +410,17 @@
>>>> * A nesting count is maintained so that rt_task_suspend() and
>>>> * rt_task_resume() must be used in pairs.
>>>> *
>>>> + * Receiving a Linux signal causes the suspended task to resume
>>>> + * immediately.
>>>> + *
>>>> * @param task The descriptor address of the affected task. If @a task
>>>> * is NULL, the current task is suspended.
>>>> *
>>>> * @return 0 is returned upon success. Otherwise:
>>>> *
>>>> + * - -EINTR is returned if a Linux signal has been received by the
>>>> + * suspended task.
>>>> + *
>>>> * - -EINVAL is returned if @a task is not a task descriptor.
>>>> *
>>>> * - -EPERM is returned if the addressed @a task is not allowed to
>>>> sleep
>>>> @@ -463,9 +469,12 @@
>>>> goto unlock_and_exit;
>>>> }
>>>>
>>>> - if (task->suspend_depth++ == 0)
>>>> + if (task->suspend_depth++ == 0) {
>>>> xnpod_suspend_thread(&task->thread_base, XNSUSP,
>>>> XN_INFINITE, XN_RELATIVE, NULL);
>>>> + if (xnthread_test_info(&task->thread_base, XNBREAK))
>>>> + err = -EINTR;
>>>> + }
>>>>
>>>> unlock_and_exit:
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
--
Philippe.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-04-15 7:20 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-14 3:53 [Xenomai-help] Suspended task resumed without rt_task_resume ? Tomas Kalibera
2008-04-14 8:21 ` Philippe Gerum
2008-04-14 8:26 ` Philippe Gerum
2008-04-14 20:01 ` Tomas Kalibera
2008-04-14 20:32 ` Philippe Gerum
2008-04-14 20:50 ` Tomas Kalibera
2008-04-15 7:20 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.