Re: [Xenomai-core] [Patch] bre^H^H^H^H reworking self deletion, take 3.

[Philippe Gerum <rpm@xenomai.org>]

Gilles Chanteperdrix wrote:
> On Fri, Feb 1, 2008 at 11:10 AM, Philippe Gerum <rpm@xenomai.org> wrote:
>> Gilles Chanteperdrix wrote:
>>  > Gilles Chanteperdrix wrote:
>>  >  >
>>  >  > Hi Philippe,
>>  >  >
>>  >  > here comes a new patch on the theme "reworking self deletion". This
>>  >  > time, execution of nkpod delete hooks is made before the context switch
>>  >  > whereas finalizing the thread takes place after the context
>>  >  > switch. Special care has been taken to call xnfreesync before we run the
>>  >  > hooks, in order to avoid freeing the thread control block before the
>>  >  > finalization, and xnheap_t::idleq was made a per-cpu thing for the same
>>  >  > purpose.
>>  >  >
>>  >  > I made a simple watchdog test with all debugs enabled, and
>>  >  > xnshadow_unmap did not complain.
>>  >  >
>>  >  > If you are OK with this patch, I will rebase the unlocked context switch
>>  >  > patch on it.
>>  >
>>  > Thinking a bit more about the unlocked context switch case: do we
>>  > tolerate that an ISR may delete a thread that is not current ? Because
>>  > if an ISR deleted a non current thread, we would not run the hooks over
>>  > the deleted thread context, so we would be again in the case where
>>  > xnshadow_unmap is not run by current. Besides, at first sight, it seems
>>  > to simplify greatly the case of the unlocked context switch.
>>  >
>>
>>  No we don't; thread deletion is normally a service callable from thread
>>  context only. We allow the watchdog code to call into
>>  xnpod_delete_thread() as an exception, because we have no other mean to
>>  fix the runaway situation properly, and we know that this will work
>>  precisely because the deleted thread is current.
>>
>>  Any other situation would lockup, because the termination signal would
>>  never make it to the runaway thread since Linux is starved from CPU at
>>  that point, and we can't even relax the thread either. So, yes, we may
>>  safely assume that thread deletion is either called from a thread, or
>>  called on behalf of an ISR for the preempted thread only (and solely for
>>  internal code and well-know situations).
> 
> Unfortunately, my reasoning was UP only, in SMP, it may happen that a
> distant CPU deletes from a valid context the thread being currently
> switched out with nklock unlocked on current CPU. So, we have to take
> care about this case anyway.
> 

IIUC, this should only be a problem with kernel threads, others would
end up self-deleting on behalf of a termination signal from the remote CPU.

-- 
Philippe.