Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>> On Tue, May 13, 2008 at 11:10 AM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
>>> Gilles Chanteperdrix wrote:
>>> > On Tue, May 13, 2008 at 10:26 AM, Jan Kiszka <[EMAIL PROTECTED]> 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
> 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
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Xenomai-core mailing list