Re: [Xenomai-core] [PATCH] Flush xnfree backlog after thread deletion in root context

[Jan Kiszka <jan.kiszka@domain.hid>]

Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>> On Tue, May 13, 2008 at 11:10 AM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>> Gilles Chanteperdrix wrote:
>>>  > On Tue, May 13, 2008 at 10:26 AM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>  >>  @@ -1236,6 +1236,9 @@ void xnpod_delete_thread(xnthread_t *thr
>>>  >>                 xnthread_cleanup_tcb(thread);
>>>  >>
>>>  >>                 xnarch_finalize_no_switch(xnthread_archtcb(thread));
>>>  >>  +
>>>  >>  +               if (xnthread_test_state(sched->runthread, XNROOT))
>>>  >>  +                       xnfreesync();
>>>  >>         }
>>>  >
>>>  > No, this does not look good. The point of deferring TCB freeing is
>>>  > that the TCB will be accessed shortly after it is freed.
>>>
>>>  By whom in this case? The thread was not active anymore. IIRC, the
>>>  use-after-release issue was related to self-deletions.
>> I do not remember the issue precisely, I know that it was related to
>> thread deletion hooks.
> 
> The point is that we have to run thread deletion hooks on behalf of the outgoing
> thread context; this is a strong requirement.

Yes, I remember.

> 
>  The XNARCH_WANT_UNLOCKED_CTXSW complicated the
>> issue further.

I now wonder when in this unlocked case do we schedule the tcb for
deletion - should be _before_ the switch - and what then prevents that
the tcb is flushed by some other CPU that happen to run xnfreesync while
we are unlocked during that switch. Or does XNARCH_WANT_UNLOCKED_CTXSW
imply !CONFIG_CMP?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux