* [Xenomai-help] rt_task_delete() question
@ 2006-03-30 17:48 Sean McGranaghan
2006-03-30 20:42 ` Jan Kiszka
2006-03-31 10:22 ` Philippe Gerum
0 siblings, 2 replies; 6+ messages in thread
From: Sean McGranaghan @ 2006-03-30 17:48 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/html, Size: 2134 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] rt_task_delete() question
2006-03-30 17:48 [Xenomai-help] rt_task_delete() question Sean McGranaghan
@ 2006-03-30 20:42 ` Jan Kiszka
2006-03-30 21:05 ` Philippe Gerum
2006-03-31 10:22 ` Philippe Gerum
1 sibling, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2006-03-30 20:42 UTC (permalink / raw)
To: Sean McGranaghan; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
Sean McGranaghan wrote:
> Hello all,
>
> I am posting this for a co-worker who is having problems with killing a
> real-time task. (He is joining the email list shortly but for now I will pass
> responses on to him.) Here is the scenario:
>
> 1. A Linux process starts up and detaches from the tty (daemon)
> 2. The daemon creates a xeno message queue
> 2. The daemon spawns a xeno task
> 3. The xeno task on startup binds to the queue rt_queue_bind()
> 4. The xeno task waits on the queue recv with infinite timeout
> 5. The daemon process goes to sleep in a join, waiting for the task to exit
> 6. Some time later another program starts
> 7. The other non-realtime program looks up the xeno task name via rt_task_bind()
> 8. The other non-realtime program attempts to delete the task via rt_task_delete()
> Failed Attempt #1 - Non-realtime program calls rt_task_delete() and gets
> a segmentation fault
> Failed Attempt #2 - Non-realtime program spawns a realtime task which
> binds to original task and tries rt_task_delete().
> Also gets segmentation fault.
>
> The was attempted one a system running the latest Xenomai 2.1 release.
>
> What is the preferred method to start/join threads from a non-realtime context?
>
> Any help is appreciated.
>
rt_task_delete is not supposed to work across processes (Hmm, is this
detail documented somewhere?).
Use a normal Linux signal (e.g. SIGTERM) to terminate the daemon
process. For a clean termination, you should install a signal handler in
the daemon process which triggers an organised clean-up (all
RT-resources except tasks have to be released explicitly).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] rt_task_delete() question
2006-03-30 20:42 ` Jan Kiszka
@ 2006-03-30 21:05 ` Philippe Gerum
2006-03-31 12:12 ` Sean McGranaghan
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Gerum @ 2006-03-30 21:05 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
Jan Kiszka wrote:
> Sean McGranaghan wrote:
>
>>Hello all,
>>
>>I am posting this for a co-worker who is having problems with killing a
>>real-time task. (He is joining the email list shortly but for now I will pass
>>responses on to him.) Here is the scenario:
>>
>>1. A Linux process starts up and detaches from the tty (daemon)
>>2. The daemon creates a xeno message queue
>>2. The daemon spawns a xeno task
>>3. The xeno task on startup binds to the queue rt_queue_bind()
>>4. The xeno task waits on the queue recv with infinite timeout
>>5. The daemon process goes to sleep in a join, waiting for the task to exit
>>6. Some time later another program starts
>>7. The other non-realtime program looks up the xeno task name via rt_task_bind()
>>8. The other non-realtime program attempts to delete the task via rt_task_delete()
>> Failed Attempt #1 - Non-realtime program calls rt_task_delete() and gets
>> a segmentation fault
>> Failed Attempt #2 - Non-realtime program spawns a realtime task which
>> binds to original task and tries rt_task_delete().
>> Also gets segmentation fault.
>>
>>The was attempted one a system running the latest Xenomai 2.1 release.
>>
>>What is the preferred method to start/join threads from a non-realtime context?
>>
>>Any help is appreciated.
>>
>
>
> rt_task_delete is not supposed to work across processes (Hmm, is this
> detail documented somewhere?).
>
Nope, basically because I totally overlooked the issue... but we should
make this possible, since rt_task_suspend() is already system-scoped.
Ok, this one is on my todo list.
> Use a normal Linux signal (e.g. SIGTERM) to terminate the daemon
> process. For a clean termination, you should install a signal handler in
> the daemon process which triggers an organised clean-up (all
> RT-resources except tasks have to be released explicitly).
>
> Jan
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] rt_task_delete() question
2006-03-30 17:48 [Xenomai-help] rt_task_delete() question Sean McGranaghan
2006-03-30 20:42 ` Jan Kiszka
@ 2006-03-31 10:22 ` Philippe Gerum
2006-03-31 14:20 ` Philippe Gerum
1 sibling, 1 reply; 6+ messages in thread
From: Philippe Gerum @ 2006-03-31 10:22 UTC (permalink / raw)
To: Sean McGranaghan; +Cc: xenomai
Sean McGranaghan wrote:
> Hello all,
>
> I am posting this for a co-worker who is having problems with killing a
> real-time task. (He is joining the email list shortly but for now I will
> pass responses on to him.) Here is the scenario:
>
> 1. A Linux process starts up and detaches from the tty (daemon)
> 2. The daemon creates a xeno message queue
> 2. The daemon spawns a xeno task
> 3. The xeno task on startup binds to the queue rt_queue_bind()
> 4. The xeno task waits on the queue recv with infinite timeout
> 5. The daemon process goes to sleep in a join, waiting for the task to exit
> 6. Some time later another program starts
> 7. The other non-realtime program looks up the xeno task name via
> rt_task_bind()
> 8. The other non-realtime program attempts to delete the task via
> rt_task_delete()
> Failed Attempt #1 - Non-realtime program calls rt_task_delete()
> and gets
> a segmentation fault
> Failed Attempt #2 - Non-realtime program spawns a realtime task
> which
> binds to original task and tries
> rt_task_delete().
> Also gets segmentation fault.
>
Eeek... 100% reproducible here. Blatant bug. More later. Thanks for
reporting.
> The was attempted one a system running the latest Xenomai 2.1 release.
>
> What is the preferred method to start/join threads from a non-realtime
> context?
>
> Any help is appreciated.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] rt_task_delete() question
2006-03-30 21:05 ` Philippe Gerum
@ 2006-03-31 12:12 ` Sean McGranaghan
0 siblings, 0 replies; 6+ messages in thread
From: Sean McGranaghan @ 2006-03-31 12:12 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai, Jan Kiszka
[-- Attachment #1: Type: text/html, Size: 3808 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] rt_task_delete() question
2006-03-31 10:22 ` Philippe Gerum
@ 2006-03-31 14:20 ` Philippe Gerum
0 siblings, 0 replies; 6+ messages in thread
From: Philippe Gerum @ 2006-03-31 14:20 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Philippe Gerum wrote:
> Sean McGranaghan wrote:
>
>> Hello all,
>>
>> I am posting this for a co-worker who is having problems with killing
>> a real-time task. (He is joining the email list shortly but for now I
>> will pass responses on to him.) Here is the scenario:
>>
>> 1. A Linux process starts up and detaches from the tty (daemon)
>> 2. The daemon creates a xeno message queue
>> 2. The daemon spawns a xeno task
>> 3. The xeno task on startup binds to the queue rt_queue_bind()
>> 4. The xeno task waits on the queue recv with infinite timeout
>> 5. The daemon process goes to sleep in a join, waiting for the task to
>> exit
>> 6. Some time later another program starts
>> 7. The other non-realtime program looks up the xeno task name via
>> rt_task_bind()
>> 8. The other non-realtime program attempts to delete the task via
>> rt_task_delete()
>> Failed Attempt #1 - Non-realtime program calls
>> rt_task_delete() and gets
>> a segmentation fault
>> Failed Attempt #2 - Non-realtime program spawns a realtime
>> task which
>> binds to original task and tries
>> rt_task_delete().
>> Also gets segmentation fault.
>>
>
> Eeek... 100% reproducible here. Blatant bug. More later. Thanks for
> reporting.
>
>> The was attempted one a system running the latest Xenomai 2.1 release.
>>
>> What is the preferred method to start/join threads from a non-realtime
>> context?
>>
>> Any help is appreciated.
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>
>
>
Fixed in the trunk/ and 2.1 maintenance branches (commits #827 and #828).
The attached patch should apply properly on 2.1.0 with only a few hunks.
Index: src/skins/native/task.c
===================================================================
--- src/skins/native/task.c (revision 822)
+++ src/skins/native/task.c (working copy)
@@ -212,7 +212,7 @@
{
int err;
- if (task) {
+ if (task && task->opaque2) {
err = pthread_cancel((pthread_t)task->opaque2);
if (err)
return -err;
@@ -349,6 +349,9 @@
int rt_task_join (RT_TASK *task)
{
+ if (!task->opaque2)
+ return -ESRCH;
+
return -pthread_join((pthread_t)task->opaque2, NULL);
}
Index: ksrc/skins/native/syscall.c
===================================================================
--- ksrc/skins/native/syscall.c (revision 822)
+++ ksrc/skins/native/syscall.c (working copy)
@@ -207,7 +207,12 @@
err = __rt_bind_helper(curr,regs,&ph.opaque,XENO_TASK_MAGIC,NULL);
if (!err)
+ {
+ /* We just don't know the associated user-space pthread
+ identifier -- clear it to prevent misuse. */
+ ph.opaque2 = 0;
__xn_copy_to_user(curr,(void __user *)__xn_reg_arg1(regs),&ph,sizeof(ph));
+ }
return err;
}
Index: ksrc/nucleus/shadow.c
===================================================================
--- ksrc/nucleus/shadow.c (revision 822)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -327,7 +327,14 @@
case LO_SIGNAL_REQ:
- send_sig(rq->req[reqnum].arg,p,1);
+ /* Special case: SIGKILL should always be sent to the
+ entire thread group. */
+
+ if (rq->req[reqnum].arg == SIGKILL)
+ kill_proc(p->pid,SIGKILL,1);
+ else
+ send_sig(rq->req[reqnum].arg,p,1);
+
break;
}
}
@@ -790,7 +797,7 @@
xnpod_fatal("xnshadow_unmap() called from invalid context");
#endif /* CONFIG_XENO_OPT_DEBUG */
- p = xnthread_archtcb(thread)->user_task;
+ p = xnthread_archtcb(thread)->user_task; /* May be != current */
magic = xnthread_get_magic(thread);
@@ -819,11 +826,11 @@
if (p->state != TASK_RUNNING)
{
/* If the shadow is being unmapped in primary mode or blocked
- in secondary mode, the associated Linux task should also
- die. In the former case, the zombie Linux side returning to
- user-space will be trapped and exited inside the pod's
- rescheduling routines. */
- schedule_linux_call(LO_WAKEUP_REQ,p,0);
+ in secondary mode, the entire thread group associated with
+ the mapped task should also die. In the former case, the
+ zombie Linux side returning to user-space will be trapped
+ and exited inside the pod's rescheduling routines. */
+ schedule_linux_call(LO_SIGNAL_REQ,p,SIGKILL);
return;
}
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-03-31 14:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-30 17:48 [Xenomai-help] rt_task_delete() question Sean McGranaghan
2006-03-30 20:42 ` Jan Kiszka
2006-03-30 21:05 ` Philippe Gerum
2006-03-31 12:12 ` Sean McGranaghan
2006-03-31 10:22 ` Philippe Gerum
2006-03-31 14: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.