* [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 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-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-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.