Re: [Xenomai-help] rt_task_delete() question

[Philippe Gerum <rpm@xenomai.org>]

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.